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PREFACE 


This  manual  describes  the  User  Requirements 
Language  (URL)  to  be  used  with  Version  3.3 
of  the  User  Requirements  Analyzer  (URA). 

The  manual  consists  of  two  volumes  which 
are  referred  to  as  Part  I and  Part  II  in  the 
documentation.  Part  I gives  a detailed 
description  of  the  URL  statements  available 
and  their  vise.  Part  II  is  a reference  mwryiyii 
which  gives  the  proper  syntax  for  each 
statement . 


FOREWORD 


ii 


User  Requirements  Language  (URL)  is  a language  for  describing  an  Infor- 
mation Processing  System  (IPS).  A Problem  Statement  (PS)  in  URL  can  be 
used  to  describe  the  "present"  system  or  to  state  requirements  that  a 
"proposed"  target  system  is  to  fulfill.  Describing  the  "present"  system 
is  helpful  in  finding  where  redundant  information/exists,  standardizing 
procedures,  etc.,  and  also  forms  the  basis  for  designing  "proposed"  sys- 
tems. In  describing  a "proposed"  system,  the  Problem  Statement  can  be 
considered  as  the  specifications  for  the  succeeding  stages  in  the  system 
life  cycle,  i.e.,  in  the  physical  design  and  construction  phases. 

Requirements  for  proposed  information  processing  systems  are  usually 
described  in  the  Logical  System  Design  phase  sometimes  called  the 
"feasibility  study."  The  end  result  of  the  logical  system  design 
process  is  a description  of  a proposed  system  and  a benefit/cost  analysis 
of  the  value  of  building  it.  The  process  itself  may  be  accomplished  in 
many  different  ways  but  the  particular  method  chosen  does  not  affect  the 
form  of  the  final  result.  What  constitutes  a satisfactory  description  of 
the  proposed  system  is  not  affected  by  whether  the  process  is  carried  out 
manually  or  with  computer  aids  (except  for  the  fact  that  the  computer- 
aided  method  can  result  in  the  description  itself  being  stored  in  a 
computer-aided  procesSable  form). 

The  purpose  of  the  manual  is  to  describe  how  URL  may  be  used  to  describe 
systems.  It  may  be  used  as  an  introduction  to  the  use  of  URL  and  is 

also  used  as  a text  in  URL  courses.  It  contains  the  complete  syntax  and 

semantics  of  URL  as  well  as  providing  guidelines  on  how  these  are 

intended  to  be  used.  A more  precise  statement  of  URL  is  given  in  the 
User  Requirements  Language,  Language  Reference  Manual,  Part  II.  Addi- 
tional information  in  the  use  of  URA  is  given  in  the  User  Requirements 
Analyzer  User's  Manual. 
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1.  INFO  A? I ON  DrOC  F SETN  0 SYSTEM  DESCRIPTION 


In  for  si*  * ion  Processing  Systems  of  all  types  exist  in 
orqan iza t ion s voday.  They  serve  tc  store,  retrieve,  manipulate 
or  organize  information  in  some  manner  to  meet  a particular 
orqa n ira  vion  ' s needs.  For  this  reason,  the  desiqn  and  operation 
of  one  of  thesa  systems  are  particular  to  a qiven  organization, 
"o  conform  with  *-he  chanqing  environment,  an  organization  must 
develon  new  systems,  modify  existing  systems  and  terminate 
obsolete  ones.  This  can  require  a malor  effort  of  the 
organization  to  design  systems  and  maintain  documentation  of  a 
system  orc«  it  is  operational. 


1 • 1 Introduct ion 


1.1.1  ~y stem  Life  Cycle 

An  information  orocessinq  system  has  a life  cycle  which  begins 
with  the  initial  conceotion  of  need  of  the  system,  proceeds 
through  determination  of  requirements  for  the  system,  (logical 
system  design),  physical  system  design,  detailed  desiqn  and 
construction,  operation,  modification  and  maintenance  and 
finally,  termination  of  system  operation. 


1.1.2  Documentat  jon 

At  each  steo  of  the  life  cycle,  some  form  of  documentation  is 
need  •»*  by  fiiP  organization.  Th«=  documentation  consists  of  a 
comolete  and  comprehensive  description  of  the  proposeed  (or 
target)  system.  7r  addition,  the  organization  of  which  the 
system  is  part  must  be  at  laast  partially  described;  and  the 
oroiect  defiring  and  designinq  the  system  must  also  be 
described . 


1. 1.2.1  What  has  fo  be  documented 

Mo  matter  what  t ypp  0f  system  is  to  be  designed  or  who  is 
designing  it,  ‘■here  exist  some  features  or  components  which  are 
common  to  all  systems  and  that  must,  therefore,  be  included  in 
its  documentation.  together,  these  common  characteristics  can 
be  reqarded  as  constituting  a modpl  of  the  system.  This  model 
is  shown  in  figu re  1 . 

"he  tasic  purpose  for  constructing  a system  is  to  serve  some 
organization.  Usually,  a new  system  is  required  to  solve  some 
"problem"  within  the  existing  system. 
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Figure  1 : The  Problem 


The  task  of  the  system  builders  is  to  accurately  define  the 
oroblem  so  that  a solution  may  be  implem ented . The  problem, 
therefore*  has  three  basic  componehts  or  elements: 

- An  environment  in  which  the  problem  occurs.  Those  parts  of 
the  orqahiration  which  directly  interface  with  the  problem  must 
be  included  in  the  description. 

- The  target  svstem  which  is  being  described  to  resolve  the 
problem.  The  word  "target0  connotes  a "proposed”  rather  than  an 
existing  system.  The  relation  between  the  environment  and  the 
target  system  is  shown  in  Figure  1. 

- The  Project  assigned  the  task  of  defining  the  problem, 
adequately  documenting  the  requirements,  designing,  constructing 
and  installing  the  system. 

Ml  cf  + he  elem»n  + s must  be  documented  in  sufficient  detail  to 
meet  the  needs  of  the  organization.  To  accomplish  this*  the 
elements  must  be  broken  down  tc  smaller  components.  These  in 
turn  must  be  broken  down  or  subdivided  into  smaller  elements. 

The  elements  at  all  levels  are  called  the  "system  description 
elements. " 


1 . 1 . 2 . 2 Purposes  of  Documentation 

description  of  the  problem  throughout  the  life  cycle  is 
usually  referred  to  as  "documentation."  Such  documentation  must 
serve  a number  of  different  purposes: 

* The  system  builders  must  have  a record  of  what  they  have  done. 

- The  organizations  within  the  environment  of  which  the  system 
is  to  serve  must  have  a description  to  assure  themselves  that 
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the  prepared  system  will  satisfy  their  needs. 

-The  management  of  the  organization  that  is  providing  the 
resources  mist,  k now  what  they  are  approving. 

- ”hp  system  builders  who  will  continue  the  development, 

cons truction , operation  and  maintenance  of  the  system  must  all 
have  doc unen Nation  from  which  to  carry  out  their  tasks. 

1.1.2.?  Form  s of  Document  at  ion 

To  serva  their  needs,  uos'  organizations  have  developed  standard 
doou men* ation  orocedures  consisting  of  verv  general  to  very 
soecific  guidelines  in  producing  documentation.  Some 
organizations  use  commercial  documentation  packages  or 
documentation  techniques  in  hopes  of  producing  more  complete, 
correct  and  consistent  documentation. 

Tt  is  standarl  nract  ice  to  record  the  description  of  the  system 
in  formal  documents  corresponding  to  various  stages  of  the  life 
cycle  known  ty  such  names  as  the  system  definition  report, 
system  requirements  report,  system  desiqn  report,  programming 
documentation,  user's  manual,  etc. 

"hose  documents  are  normally  in  narrative  form,  supplemented  by 
diagrams,  flow  charts,  lists,  glossaries,  cross  references,  etc. 

1 . 1 . 2 . 4 Char  act  eristics  of  System  Docuroentat  ion 

Information  Processing  Systems  are  large  and  complex  and 
reqardless  of  who  nroduces  the  documentation  or  what  graphical 
ails,  such  as  f 1 ow  charts  are  used,  it  will  have  several 
features  that  make  the  process  of  documentation  different. 

- Size.  Complete  documentation  of  a system  may  consist  of  many 
thousard  of  naqes  of  charts,  tables,  code  listings,  user  guides, 
proiect  plans,  e*-c. 

- Complexity.  Anv  piece  of  information  about  some  aspect  of  the 
system  cr  the  proi°ct  may  be  related  to  many  oth^r  pieces. 

- Multiple  users  with  different  needs.  Each  of  the  users  of  the 
',ocn  ment  ation , as  noted  above,  need  the  documentation  of  some 
aspects  of  the  systom  a*  different  levels  of  detail. 

- Ch  argeabi  l itv.  "he  documentation  must  be  constantly  undated 
as  chances  occur  in  the  organization  or  in  the  system.  Any 
change,  because  of  the  complexity,  can  affect  the  documentation 
in  many  places. 
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1.1.3  Process  of  Poc  u ment, at i on 
1 . 1 . 3 . 1 Manual 

Someone  inns*-  be  responsible  for  this  documentation.  It  is  often 
the  task  of  the  analyst  to  So  this.  In  other  cases,  it  may  be  a 
'■echriral  writer  Who  must  obtain  the  information  from  other 
sources  (analysts,  management,  memos,  etc.)  in  order  to  produce 
the  documentation  of  the  system.  the  technical  writer  has  the 
disadvantage  of  not  beino  directly  involved  in  the  system 
development  effort.  The  analyst  has  the  advantage  of  being 
directly  involved  with  the  system  yet  is  sometimes  toO  close  to 
it  to  present  a complete  description.  The  documentation  is 
usually  product  manually  regardless  of  who  is  doing  it. 

1 . 1 . 3 . 2 Computer-Aided  Documentation  - tlRl/URA 

A cnmpu'-er-a  i ded  approach  to  system  documentation  can  be  an 
improvement  over  the  manual  methods  by  using  the  power  of  the 
computer  to  store  large  nuar.titios  of  data  and  to  manipulate 
complex  relationships. 

”o  take  advantage  of  the  potential  benefits,  a computer-aided 
documentation  system  should  hdv€  the  following  characteristics: 

a)  A formal  language  flexible  ehouqh  to  describe  any  tyoe  of 
information  processing  system. 

b)  A translator  which  *-akes  the  formal  language  statements  as 
input  and  stores  it  i n some  prdcessable  form  in  the  computer 
(i.e.fr  on  disk  or  tape). 

c)  A data  basa  .in  which  the  information  interpreted  from  the 
languaoe  sta  *■  em  ->  n*  s is  stored. 

d)  A report  generator  which  allows  information  in  the  data  base 
to  be  retrieved,  anaiyred  and  formatted  as  teports. 

e)  An  update  facility  which  allows  information  in  the  data  base 
no  be  added  to,  modified,  or  deleted.  Before  any  information  in 
the  data  base  is  updated,  checks  must,  be  made  for  consistency 
and  correctness  so  that  accuracy  of  the  information  in  the  data 
base  is  maintained. 

The  advantaoes  of  using  such  a computer-aided  technique  versus  a 
manual  method  ar°: 

a)  Though  i n^or ma*i on  is  interrelated  with  other  information, 
there  is  only  one  occurrence  of  each  piece  of  information  in  the 
data  base.  if  this  piece  of  information  is  modified,  the 
contents  of  th°  data  base  are  modified  to  reflect  the  change. 

b)  The  LannUaae  has  a finite  number  of  statements  which  may  be 
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eD^cified  and  svntax  and  semantic  rules  for  each  of  these 
star  omen  ts.  This  allows  persons  documenting  systems  to  give 
precise  descriptions  which  are  much  less  subject  to 
mi  si  n ter p relation. 

c)  Pnce  the  data  base  has  been  modified,  all  reports  qanerated 
using  it  are  up-to-date. 

d)  The  reports  generated  are  designed  to  view  the  system  (as 
described  in  *he  data  base)  at  various  ancles.  One  particular 
report  may  present  high  level  structural  information,  another 
may  presen*-  the  manner  in  which  low  level  data  is  manipulated  in 
the  system,  and  s*ill  others  may  present  lists  of  names, 
dictionaries,  etc. 

e)  Seme  reports  may  present  results  of  complex  analysis  based 
on  the  contents  of  the  data  base.  Analysis  may  consist  of 
checks  for  completeness  or  consistency  in  the  system  description 
at  any  point  in  time. 


1 . 1 . 3 . 3 UPL/DfA 

URL  is  a com  nute r-processabl*3  language  designed  primarily  to 
describe  a target  system  during  its  formative  stage  (i.e., 
during  the  determination  of  requirements  phase  in  the  system 
life  cycle).  It  also  contains  facilities  for  describing  those 
parts  of  the  organization  interfacing  with  the  system  and  those 
parts  of  the  projec*  which  are  relevant  to  the  description  of 
the  target  system.  The  DFL  description  of  a system  consists  of 
a combination  of  formal  statements  (allowed  by  the  language) 
supplemented  by  narrative  descriptions. 

Th=»  riser  Peguirements  Analyzer  (OPA)  is  a software  package  which 
processes  the  hrt,  statements  and  acts  as  an  interface  between 
the  problem  definers  and  the  information  stored  as  the  nPL 
description. 

Organizations  usually  require  that  the  documentation  of  a 
proposed  system  include  a "system  requirement  report."  This 
document  contains  a detailed  description  of  the  target  systei, 
informavion  about,  the  manner  in  which  the  system  interfaces  with 
the  organization,  and  some  description  of  the  project  designing 
the  system  including  estimates  of  costs,  resources  required  and 
completion  time,  etc.  HPL  is  designed  to  state  the  type  of 
information  which  appears  in  the  system  requirement  report  and 
when  a problem  is  completely  described,  essentially  all  the 
information  for  the  system  requirement  report  is  contained  in 
the  OPA  data  base. 


P APT  1 USER  REQUIREMENTS  LANGUAGE  MANUAL 


H61  «0/SfJLTrCS/nPT,  TISSB'S  MANUAL 


6 


1 . 1 . 4 Introduction  to  npi  - a Fopmal  System  Description  Language 

Thr>  description  of  a system  involves  describing  "objects,"  the 
"properties"  of  these  objects,  and  the  "relationships"  among  the 
objects, 

Tn  Section  1.1.2  these  "objects"  were  referred  to  as  "system 
description  elements"  representing  some  physical  or  conceptual 
thing  in  the  *arget  system,  Examples  of  "objects"  are  "logical 
collections"  of  data,  the  "processes"  which  define  how  the  data  j 

is  derived,  etc,  ?tch  "object"  defined  in  the  target  system 

must  be  assigned  a unioue  name  and  classified  by  the  "type"  of  | 

ohlect  which  if  is.  UFL,  for  example,  allows  approximately  30 
different  typos  of  "obiects." 

"Properties"  of  an  "obdect"  consist  of  statements  describing 
that  "object." 

\ 

"Relationships,"  on  the  other  hand,  describe  connections  among 
"objects."  To  say  that  object  A uses  objects  B and  C specifies 
"relationships"  among  these  objects.  There  are  approximately  75  j 

different  "relationships"  that  may  be  used  in  URL . 

An  example  of  a description  of  a (very  simple)  system  is  given 
in  Section  1.2.  P full  description  of  the  types  of  "objects" 
that  may  be  defined  in  fJPL,  their  purposes  and  usages,  is  given 
in  Sect' on  1,3.  The  "relationships"  allowed  in  URL  are  given  in 
Section  1.4  along  wi*h  information  on  how  these  relationships 
relate  to  the  overall  system  description  and  special 
considerations  involved  when  using  them. 


1 . 2 Fxam  pie 

"his  sf'cMon  illustrates  the  fundamental  concepts  of  objects, 
names  of  objects,  types  of  objects  and  relationships  among 
obdects  through  the  use  of  a simple  example.  The  process  of 
computer-aided  documentation  is  also  shown.  (Properties  of 
objects  are  not  illustrated  in  this  example.) 


1.2.1  Narraf  i ve  Qescr  ipt  jor. 

The  following  is  a typical  narrative  description  of  a particular 
syst  em : 

"A  system  called  payroll  processing  takes  employee 
information  which  comes  from  departments  and  employees  and 
produces  outputs  which  go  to  the  departments  and  employees. 
The  system  also  maintains  payroll  master  information." 

"he  information  in  such  a narrative  description  is  usually  shown 
graphically  as  in  Figure  1.2.1  or  in  Figure  1.2. 1.1. 
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^Iqure  1.2. 1.1 

System  Flowchart  for  PA  YSYSTEM 
Using  Standard  Flowchart  Symbols 


,.2.2  Id PiUi fiction  of  2i2ii£iS 

■"he  first.  5t#o  in  usinq  URL  is  to  identify  the  objects  in  the 
system  h«inq  described.  This  can  he  done  for  the  above  example 
hv  underlining  them  in  the  narrative  description: 

"A  sistgm  called  2§i£2li  processing  takes  employee 

inf  9P»a 1 jpn  which  comes  from  departments  a.a^  employees  and 

produces  23£E3£§  which  go  to  the  department?  ajid  employees. 
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The  sy s t om  also  maintains  payroll  waster  information.  " 


1.2.  1 oh  -jecv  Names  jr  j Ty pes 

pach  of  the  defined  objects  has  a unigue  name  and  each  of  these 
objects  is  described  in  a different  context;  "employee 
information"  represents  information  passing  from  "departments 
and  employees"  ‘o  "payroll  processing, " "payroll  master 
information"  represents  information  manipulated  by  "payroll 
nronp.'sinq, " etc.  In  effect,  each  of  these  objects  represent 
different  types  or  classes  of  objects.  For  example,  in  URL,  the 
type  of  ohjec‘  corresponding  to  that  suggested  by  "employee 
information"  is  an.  INPUT,  "payroll  master  information"  is  a SET, 
etc.  The  following  table  relates  each  of  the  obiects  defined  in 
the  narrative  description  with  a corresponding  URL  name  and 
object  type; 

UP  L 

Ob  ject 

Narrative  URL  Name  Type 


payroll  processing 
employee  information 
departments  and  employees 

outputs 

oavrcll  market  information 


payroll -pro cessing 
empl oyee- in  forma t ion 
depar  tments-and -employees 

p a ysys tern- outputs 

pay roll-mas ter- inf or mat ion 


PROCESS 

INPUT 

INTER- 

FACE 

OUTPUT 

SET 


URL  does  no*-  allow  blanks  in  the  names  of  objects;  dashes  are 
normally  used  ‘o  connect  names  consisting  of  more  than  one  word. 
In  an  effort  to  k«ep  the  names  used  as  meaningful  as  possible, 
"oualified"  names  such  as  "paysystem-outputs"  (instead  of 
"outputs")  ar°  encouraged. 


1.2.4  Id enti f ica t ion  of  Relationships 

"he  next  step  in  using  URL  is  to  identify  the  relationships 
among  *he  objects  which  have  been  identified.  The  relationships 
implied  in  the  example  narrative  description  are  underlined; 

"A  system  called  payroll  processing  takes  employee 
informa ‘ion  which  comes  from  departments  and  employees  and 
pro  duces  outputs  which'go  to  the  departments  and  employees, 
"he  system  also  maintains  payroll  master  information." 

"he  following  relationships  have  been  identified; 
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”ela  tionship  Between 


♦•akps 
com*5  a 
prod  uces 
<30 

maintains 


payroll  processing 
employee  information 
payroll  processing 
outputs 

payroll  processing 


employee  information 
departments  and  employees 
outputs 

departments  and  employees 
payroll  master  information 


"here  ar « a finite  number  of  relationships  that  may  be  described 
bv  PPL.  By  taking  into  account  the  types  of  objects  defined  in 
the  above  example  and  the  relationships  that  URL  allows  among 
those  objects,  the  following  correspondence  between  the 
narrative  description  relationships  and  the  URL  relationships 
can  be  made: 


E£l3tifinshi£  UfL  relationship 


takes 


RECEIVES 


comes 

produces 

go 

maintains 


GENERATED  BY 
GENERATES 
RECEIVED  BY 
UPDATES 


The  description  of  the  system  using  URL  terminology  is: 


Object 


B§la&i2&&klE  ObjJect 


payroll-  prccessi  ng 
empl cyee-inf  orma  tion 
payroll- processing 
pay  system-out.  puts 
payroll- process! no 


RECEIVES 
GENERATED  BY 
GENERATES 
RECEIVED  BY 
UPDATES 


em  ploy ee-in format! on 
departments-and-ea  ploy  ees 
pa  ysystem- outputs 
departments-and-ea  ploy  ees 
payrol  1-master-inf  orma  tion 


1.2.5  JJ£L  Format 

""he  object  type  of  a particular  named  object  can  be  explicitly 
defined  by  a URL  statement.  For  the  above  example,  the 
following  URL  statements  may  he  used  to  define  the  object  type 
of  "payroll  processing,"  "employee  information"  and  "departments 
and  employees." 

PROCESS  pay  roll-processing; 

TNPrT  emplovee-informationj 

INHERE  ACE  dep  artment s-an d-employees; 

Since  a particular  object  may  be  involved  in  several 
relationships  the  format,  for  specifying  relationships  is  made  as 
simple  as  possible.  For  any  object,  defined  via  a statement 
declaring  its  object  type  (as  above)  those  relationships  the 
object  is  Involved  in  may  be  listed  after  this  statement  along 
with  the  corresponding  objects  in  the  relationship.  The  URL 
format  to  specify  ♦he  relationships  "payroll  processing"  is 
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involved  in  i -■> t 


pay  roll- processing; 
employee-information; 
pay  system-out  puts; 
pay  roll- mas  ter- in  format  ion; 


"ROCEFS 

•>ecf:ves 

GE  NFRATES 
UP  C AT? c 


1.1. f 211  Outputs 


One  complete  PPL  problem  statement  for  the  example  is  shown 
below.  (There  are  many  ways  in  which  all  of  the  information 
could  be  stated.  They  are  all  equivalent  as  far  as  URA  is 
concerned .) 


IN  PUT 
OUTPU"' 

ST“r 

7 N rr  E ? F ACE 
GFNFPATE  S 
?FCE'rV5S 
rF  OCF^  F 
UPDATE? 

F EC  E I Vr  S 
G EM F PAT v F 


employe e-in  for mat  ion; 
pay  system-outputs ; 
nay  roll-master-information; 
dep  a rtments-and- employees; 
employee- information; 
p ays vs tem -out puts; 
oay  roll-  process  in  q ; 

payroll-master- information; 
emol oyee- information; 
p a ysvs tern -out  puts; 


°n ce  these  statements  have  been  entered  into  the  DPA  data  base, 
rip  A car  be  used  to  qenerate  a number  of  "standard"  outputs. 
Piaure  1 . 2. c shows  one  of  these  outputs  called  the  FORMA  T^ED 
npoPLFF.  STATEMENT.  This  report  contains  all  information  stored 
about,  selected  objects  in  the  data  base,  in  this  instance,  the 
r°nort  has  beer  generated  for  all  the  objects  defined  ia  the 
data  base. 


"he  format  of  t.ha  information  in  the  FORMATTED  PROBLEM  STATEMENT 
is  the  same  as  that  specified  when  describinq  the  example  in 
U°L.  The  report  also  presents  all  implied  relationships  as  well 
as  the  explicitly  defined  ones.  ""his  is  the  reason  that,  thouqh 
only  five  relationships  were  given  in  the  example,  ten  are 
presented  in  the  FPCM  AT^ED  PROBLEM  STATEMENT . To  say  that 
’ nav rcll- process ing • RECEIVES  ’employee- information ' implies 
that  'em  oloy  e<?- i nfor  mat  ion*  is  RECEIVED  BY  • payroll- proc  essinq , • 
etc.  ■"hefie  are  called  complementary  statements  and  when 
describinq  a system  in  UPL,  the  choice  of  which  of  the  two 
complementary  relationships  to  be  used  is  arbitrary.  (The 
information  stored  in  the  data  base  is  exactly  the  same.)  The 
following  are  the  complementary  relationships  used  in  the 
exam  cle: 
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ion  shin 


Complementary  Relationship 


RECEIVES  RECEIVED  BY 

GENERATES  GENERATED  BY 

UPDATE?  UPRATED  BY 

Figure  1.2. 6.1  presents  an  example  of  a graphical  output  that 
may  he  obtained  from  DPA.  This  particular  example  shows  the 
relationships  ' payrol 1- proce ssing ' is  involved  in.  All  objects 
are  represented  by  rectanqles  with  the  naie  of  the  object  within 
* he  rectangle  and  the  type  of  the  object  is  given  on  the  top 
line  of  the  rectangle. 


■"he  rectangle  for  the  nase  for  which  the  output  is  being 
generated  is  placed  at  the  center  of  the  diagram.  All  other 
objects  are  placed  along  the  left  and  right  margins  if  involved 
in  "flow"  relationships,  and  along  the  top  or  bottom  margins  if 
involved  in  "structure"  or  "updating"  relationships.  The  type 
of  relationship  the  center  object  has  with  bordering  objects  is 
given  or  the  bottom  line  of  the  rectangle  for  each  of  the  border 
objects.  In  the  diagram,  'payroll-processing'  RECEIVES 
' emplcvee-in  f crma  tion  , ' etc. 

In  this  example,  names  of  objects  have  been  shown  in  lower  case 
letters  and  Types  of  Objects  and  Relationship  in  upper  case 
letters.  It  is,  therefore,  easv  to  distinguish  user  assigned 
names  for  objects  from  words  which  are  part  of  rJFL.  The  ability 
to  distinguish  lower  and  upper  case  letters  depends  on  the 
facilities  available  in  the  installation  in  which  DRA  is  being 
used.  If  the  installation  does  not  support  lower  case  letters, 
all  words  and  names  will  appear  in  upper  case. 
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1 . 3 URL  Objects 

A 'IF I object  is  anything  qiven  a URL  name  by  the  user  of 
URl/URA.  Each  object  is  given  a unique  nane  so  it  can  be 
identified  each  time  it  occurs  in  the  system  description. 
Consequently,  all  occurrences  can  be  collected  and  analyzed.  A 
URL  name  is  one  that  conforms  to  t he  rules  of  name  formation  in 
the  UFL/URA  system  (Section  1.6).  Once  any  particular  object 
has  been  given  a name  it  can  be  included  in  relationships  only 
by  specifying  its  name. 

Each  oblect  must  be  a certain  object  type.  The  complete  list  of 
permissible  types  in  alphabetical  order  is  given  in  Figure  1.3 
toqether  with  the  allowable  abbreviations  for  each  object  type. 
Of  these,  two  are  "special**  types:  SYNONYM  and  UNDEFINED.  If 
fhe  cfclect  type  of  an  object  is  not  declared  explicitly,  URA  may 
be  able  to  deduce  the  object  type  from  the  manner  in  which  the 
obiect  is  used,  otherwise,  the  object  type  for  the  name  will  be 
"UNDEFINED."  A Problem  Statement  is  not  complete  if  it  contains 
any  UNUE FINED  names.  A SYNONYM  is  a special  type  of  object  that 
can  be  used  only  as  an  alias  or  pointer  to  one  other  name,  e.g., 
an  object  that  has  been  assiqned  the  name  * validation- 
processinq'  might  be  qiven  synonym  *valpr.* 
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object  Abbreviation 

^'TCTP  TJ'pi? 

AT TP IP  UTS-  VALUE 
CL  ASFIFICATO’’ 

CO  wpi^TON 
FT  £fFK'r 
7N  "‘ITT 
EVENT 

gpour 
t y r r"" 

TF  TEP.v  ACE 
rvTirpv  AL 
KEY VOF D 
M A TI  BOX 

w”  ’’o 
OUTPUT 

PROBLFE-UEFTMZ  R 

ppp^c  c 

PFPCFFSOR 
RELATION 
FE  SOURCE 

Rr  SOUF  CE-US  AGE-PAR  A METER 
SFCUPTTY 
SOUFCF 
Sr  T 

S I B SET "IN G - CR  T T FP  TO N 
SYNONYM 

S YSTFK-PAR  AEF7’ SP 
TF  ACF-KZY 
UNDEFINED 
rjw  il 

Figure  1.3  ablest  Types  and  Abbreviations 


’.3.1  Classification  of  object  Types 

For  *ase  of  describing  the  purpose  and  characteristics  of  each 
typp  of  oblect  vi*h  respect  to  the  system  documentation,  it  is 
convenient  to  group  the  types  into  classes.  The  list  of  classes 
and  oblect  tyoes  within  each  class  if  shown  in  Pigure  1.3.1.  It 
must  be  emphasized  that  classification  is  for  exposition  only 
and  plays  no  role  in  the  formal  syntax  or  semantics  of  URL.  The 
major  categories  of  classification  are  the  following: 

Organization  for  objects  used  to  describe  the 

organization  or  environment  in  which  the 
target  system  is  to  operate. 

"•arqet  System  for  objects  used  to  describe  the  target 

system . 
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ATTP 

AT7V 

CLS 

COND 

FLY 

ENT 

EVT 

GP 

IK  P 

IKTP , PWS,  ORGn 

TFT 

KEY 

BOX 

OUT 

PD 

PPC 

PPCR 

RLN 

PSC 

PUP 

SEC 

SFC 

SSCN 

SYN 

SYSP 

TKEY 
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Project  "anagem^nt  for  oblects  used  to  describe  the  project 

developing  the  target  system. 

nroper*ies  for  oblects  used  to  describe  the  objects 

in  the  above  three  categories. 

mhe  purpose  and  chac acter ist ics  of  each  object  type  is  described 
below  ir  the  order  in  which  listed  in  Figure  1.3.1.  The 
relationships  in  which  an  object  of  a given  type  can  be  included 
is  outlined  in  Section  i.4,  and  given  in  more  detail  in  Sections 
3 an  d 3.  (The  precise  syntax  is  given  in  the  "rjser  Requirements 
language,  Languaqe  Reference  Manual. "»)  A discussion  of  the  role 
of  each  object  type  and  situations  in  the  system  description 
process  whether  it  should  or  should  not  be  used  is  given  in 
Sec* ion  4. 


1.3.2  Or g an i 7 at j on  Objects 

,rhe  TIFl  object  used  to  describe  some  oart  of  the  organization  or 
on vi  rormen*-  with  which  the  target  svstem  interacts  is  called  an 
INTERFACE  (or  F^AL-VORLD- ENTITY)  . IN”SF  FACES  are  often  used  to 
describe  departments  in  an  organization  or  oth^r  information 
processing  systems  which  interface  with  the  target  system. 
Interfaces  are  sometimes  called  by  such  names  as  "stations," 
"organizational  units,"  etc.,  in  other  documentation  systems. 

Interfaces  are  objects  which,  as  far  as  th°  target  system  being 
developed,  may  receive  data  from  it  or  transmit  data  to  it.  For 
example,  if  a warehouse  stock  control  system  were  being 
designed,  interfaces  might  be  suppliers,  customers,  the 
accounting  department,  etc.  They  are  not  part  of  the  target 
svs*  e m , but  have  important  relationships  with  it.  Though  the 
functions  of  an  interface  may  be  complex,  only  the  description 
pertaining  to  its  relationships  with  the  target  system  are  of 
importance.  Interfaces  should  be  described  if  they  generate 
information  to  the  target  system,  receive  information  from  the 
♦an et  svstem,  or  are  responsible  for  information  within  the 
♦arqe*  system. 


1 "art  II  of  thin  document 
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Piqure  I.3.1  Classification  of  object  Types 
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i . 1 . 1 ""a  rgot  System  Objects 

■"unet  svs'an  ob-jects  are  ns1?;!  to  describe  the  target  system 
wi*-h  rerrxjct  to  forms  of  information,  processing  of  the 
information,  behavior  of  the  system  over  time,  etc. 

1 . R . 3.1  Collections  of  In  for  mat  ion 

Tnformation  related  to,  or  pertaining  to,  one  particular  type  0f 
thing  or  concent  is  thought,  of  as  a collection  of  information. 
cor  example,  "^mplovee  information"  may  be  a collection  of  all 
information  pertaining  to  a particular  employee.  This 
information  would  be  derived  when  an  employee  is  hired  by  the 
comoanv,  used  tQ  produce  paychecks  for  the  employee,  updated  to 
roflec*  changer,  in  the  employee's  status,  address,  etc.  '’he 
collection  is  to  be  thought  of  as  a whole  (in  the  above  example, 
everything  that  had  to  be  known  about  an  employee)  '■hough  in 
being  processed  bv  the  target  system,  only  portions  of  the 
collection  might  be  used  at  any  one  time.  There  are  three  types 
of  collections  of  information  that  may  be  defined  in'  URL: 

INPUTS,  OUTPUTS  and  ENTITIES.  The  difference  among  these  types 
of  collections  is  related  to  their  role  in  the  target  system. 


XVPTJTS 

An  IMF'!'"  is  a collection  of  information  produced  external  to  the 
target  sysfoa,  but  used  by  the  target  system.  For  example,  in 
ar.  inventory  system,  a customer  order  may  be  considered  an  INPUT 
to  ♦he  system. 


OUTPUTS 

An  OUTPUT  is  a collection  of  information  produced  by  the  target 
system,  but  which  is  used  external  to  the  system.  For  example, 
the  paychecks  produced  by  a payroll  processing  system  could  be 
thought  of  as  OUTPUT?  as  they  are  eventually  used  by  employees 
outside  of  the  svs*em.  Once  the  collection  has  left  the  system, 
no  t urth«?r  reference  may  be  made  to  it. 


FNTI TIES 


An  Tl N T T t y js  a collection  of  information  which  is  maintained 
internal  to  the  system.  ENTITIES  are  ir.itiallv  "produced"  and 
then  "maintained"  using  information  from  INPUTS  and  then  OUTPUTS 
are  produced  using  information  from  FNTITIES . The  "employee 
information"  described  above  in  the  definition  of  "Collections 
of  Information"  is  an  example  of  an  ENTITY. 

All  of  the  abov®  types  of  collections  of  information  may  belong 
to  larger  collections  and  may  be  broken  down  into  smaller  units 
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of  information.  Consequently,  there  may  he  "structural" 
relationships  between  narticular  ob-jects  of  thes°  types. 


i. 1.3.2  Collections  of  Informa  tion  Instances 

A number  of  instances  of  one  or  more  collections  of  information 
is  called  a SET.  'or  example,  a SET  miqht  he  defined  to 
describe  all  instances  of  "employee  information"  in  the  target 
system.  There  is  an  important  distinction  to  be  made  between  a 
collection  of  information  and  an  instance  of  this.  Information 
called  "employee  information"  is  a collection  of  information, 
but  employee  information  about  JACK  SMITH  is  an  instanca  of  the 
collection  of  information.  A number  of  instances  together  may 
constitute  * sym  Qf  "employee  information."  Likewise,  if  two 
collections  of  employee  information  were  maintained  (one  for 
current  employees  and  one  for  retired  employees)  a SET  could  be 
defined  *o  contain  instances  of  both  collections  as  well  as 
defining  a separate  EFT  for  each  collection  of  information  about 
the  different  types  of  employees. 

The  common  exampl®  cf  a SET  is  a master  file  consisting  of 
records,  i.a.,  FNCITTFS,  for  each  employee.  However,  SET  may 
also  consist  oF  INPUTS  and  OUTPUTS.  This  permits  SETS  to 
represent  collections  of  INPUTS,  e.g.,  queues  of  messages  to  he 
processed. 


1.3. 3.3  pela t iqn  ships  Among  Collections  of  Information 

Collections  of  information  maintained  internal  to  the  system 
fE'i"  ITE  <5)  are  often  "related"  to  each  other  in  that  there  is 
information  which  is  not  inherent  to  either  yet  is  associated 
with  both.  In  the  example  of  a warehouse  stock  control  system, 
information  about,  inventory  items  may  be  related  to  information 
about  their  suppliers,  etc.  DELATIONS  are  used  to  describe 
logical  connections  among  ENTITIES. 


1.3. 3. U Tata  bef  jnit ion 

Collections  of  information  (INPUTS,  OUTPUTS  and  ENTITIES) 
"contain"  valuer,  of  information  called  ELEMENTS  and  GROUPS. 


F L ^ v » N'T  F 


rLE*  ENTS  are  the  basic  univ  of  information  and,  therefore, 
cannot  be  subdivided.  An  ELEMENT  is  used  to  describe  a data 
oblect  which  may  take  on  a value.  For  example,  if  "employee 
information"  was  d*»tined  to  be  an  ENTITY  it  would  not,  in 
its?lf,  have  a value.  The  •‘LENENTS  makinq  up  "employee 
information"  such  as  "aqe,"  "sex,"  "salary,"  etc.,  might  have 
values  for  a particular  instance  of  "employee  information." 
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GROUPS  used  to  describe  a collection  of  ELEMENTS  and/or 

other  GFOr,r,S.  o~o'ip«  allow  the  problem  definer  to  logically 
relate  one  or  "tore  ELEMENTS  and/or  GROUPS  foqot,her  and  refer  to 
them  collectively  by  the  GFDUP  name. 

GROUPS  can  be  thought,  to  be  synonymous  with  the  names  of  the 
group's  components.  In  the  example  of  "employee  information," 
the  "name"  of  the  “tnplovee  may  be  defined  as  a f? P 0 rjp  where  the 
corctitutents  of  the  GROUP,  "first  name,"  "middle  initial," 
"surname"  may  he  defined  as  ELEMENTS.  "he  use  of  GROUPS  is 
primarily  a notational  convenience. 


1.o.?.5  gat  a Derivation 

An  information  processing  system  exists  to  process  data,  i.e., 
to  nrcduce  data  values  from  other  data  values.  This 
transformation  is  Vnown  by  different  names  such  as  process, 
procedure,  function,  operation  activity,  etc.  In  URL,  a PROCESS 
is  mhe  type  of  obiect  used  to  describe  this  transformation. 

The  total  target,  system  can  be  regarded  as  a PROCESS  at  the 
highest  level.  A PPOCESS  is  defined  by  specifying  the 
information  upon  which  it  operates  and  the  information  which  it 
prod  uces . 


Sjme  and  Volume 

Objects  which  relate  information  pertaining  to  the  amount  of 
information  maintained  by  the  system  and  volume  of  information 
to  be  processed  are  described  to  estimate  the  size  of  the  target 
system. 

Information  about  t.h*»  size  of  a proposed  tarqet  system  is 
usually  stated  in  terms  of  numbers.  E.g.,  500  employee  changes 
occur  each  oav  period  or  production  analysis  report  consists  of 
100  pages. 

In  npi,  the  "parameters"  affecting  the  sire  of  the  system  are 
considered  ohiects  and  each  given  a unique  name:  two  types  of 
oblects  are  permitted: 

SY STEM- PARAMETERS  and  time  INTERVALS 

The  tasic  purpose  of  treatinq  these  parameters  as  objects  is 
that  each  occurrence  can  be  uniquely  identified.  Consequently, 
all  occurrences  can  be  identified.  Also,  only  one  assignment  of 
numerical  values  need  be  ready,  the  assignment  can  be  as  "late" 
as  possible,  and  sensitivity-analysis  can  be  carried  out. 
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SYSTFE-PAPAMETER 

* SYS1EE-PAF AYETSP  is  used  to  reprpsent  a value  relevant  to 
characterizing  "system"  size.  A SYSTEM-PARAMETER  may  be  used  to 
describe  the  number  of  instances  of  a particular  ELEMENT  in  a 
particular  instance  of  an  ENTITY,  for  example. 


IVTEPVAL 

An  TNTFPVAL  is  used  to  describe  a unit  of  time.  In  defining 
frequency  of  an  occurrence  in  the  system,  the  frequency  must  be 
defined  with  respect  to  soma  unit  of  time.  A "year"  is  an 
example  of  an  interval,  as  is  "work-- week  . " 


1.3. 3.7  Dyna  m ic  3 ah  a vior 

The  description  of  the  dynamic  behavior  of  the  system  indicates 
requirements  on  processing  order  and  the  relationships  between 
processes  and  objects  that,  initiate,  terminate,  or  interrupt 
them  . 


”VEN  T 

An  EV^N"  is  us«»d  to  describe  possible  occurrences  during  the 
operation  of  the  taroet  system.  An  occurrence  of  an  EVEN*"  is 
associated  with  a specific  point  in  time,  but  the  same  EVEN'"  may 
occur  more  than  once  during  target  system  operation.  For 
example,  "error  recoorized"  may  be  an  EVENT  that  causes  normal 
processing  to  b*»  suspended  while  an  error  processor  is 
init iat^d. 


covpiirr  n 

A CONriTON  is  used  to  describe  some  aspect  of  the  state  of  the 
target  system.  a CO»tditTON  may  be  either  true  or  false.  For 
example,  "input  data  valid"  could  be  a CONDITION.  A change  of 
this  CONDITIO*!  f"om  true  to  false  might  cause  an  EVENT  (such  as 
"error  recoanized")  or  might  directly  initiate  error  processing. 


1.  ■>.  3.8  Sj£tem  l rchi  ‘•ecture  Objects 


PPOCESSOP 

An  object  that  car  "perform"  a PROCESS  is  a PROCESSOR.  In  other 
words,  a processor  is  an  "agent"  *hat  physically  acts  to  perform 
a ,t^CFcS.  A computer  system,  a department  in  an  organization, 
a person,  can  all  be  modeled  as  a PFOCFSSOR. 


P 
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jA 

"he  total  target  system  can  be  regarded  as  being  performed  by  a 
single  PPOC^SSO'*  at  the  hiahest  level.  This  hiqhest  level 
nogcFPSOR  is  the  collection  of  all  the  physical  entities 
(including  human  beings)  that  actually  carries  out  all  the 
information  processing  functions  in  the  system. 


PT50TPCF 

A P E SOMp CE  is  something  that  the  physical  elements  in  the  target 
system  consume  in  order  to  carry  out  information  processing 
functions.  A RESOURCE  is  consumed  , and  once  an  amount  of 
PESO  UPC''  is  consumed,  it  is  considered  unrecoverable  because  it 
is  "used  up."  Por  example,  a certain  amount  of  RESOURCE  called 
electricity  is  consumed  by  an  electrical  appliance  in  a given 
time  period.  "he  amount  of  electricity  thus  consumed  is  not 
recoverable  because  it  is  used  up. 

Tt  is  important  to  note  this  somewhat  specialized  meaning  of 
RESOURCE.  In  the  general  usage  of  the  term,  "resource"  could 
mean  something  that  is  needed  for  a task  to  be  performed,  but 
which  is  returned  after  it  is  finished.  For  example,  an 
electrical  appliance  can  be  regarded  as  a resource  in  this 
sense:  when  it  is  beinq  used  by  someone,  nobody  else  can  use  it; 
but  when  it  is  no  longer  used,  it  is  available  for  use.  In  URL 
this  second  meaning  of  "resource"  is  modeled  by  PFOCESSOR,  and 
the  term  RESOURCE  is  exclusively  used  for  the  first  meaning. 


g*jT- 

Since  it  is  necessary  to  handle  quantities  of  RESOURCES,  units 
ar<»  needed  to  measure  RESOURCES.  The  object  UNIT  is  used  for 
this  purpose.  A nNi"  is  used  to  measure  RESOURCES.  For 
example,  electricity  may  be  measured  in  a UNIT  called 
"kilowatt-hour. " 


PESO  URCE-USA  OE-PAPAMF,,'ER 

A P v SOURCE- U?A01? -PAR A ME^E P is  an  object  that  defines  a measure 
of  the  FESOUFCE  usage  for  a PROCESS.  It  is  introduced  in  URL  as 
a wav  of  exor^ssing  resource  consumption  of  a PROCESSOR 
performing  a peocrgs  independent  of  what  PROCESSOR  performs  it. 

for  example,  one  can  assign  values  for  a PESOflPCE-US AGE- 
PA PA M ETE P "no-of-fortran-steps"  to  a set  of  PROCESSes.  The 
values  of  the  p esohrcF- US AGE-PAR AE  ETF?  for  a PROCESS  might 
signify  ‘■he  number  of  FORTRAN  steps  if  the  PROCESS  is  to  be 
performed  by  » computer  and  FORTRAN  is  to  be  used  to  write  the 
program.  The  actual  amount  of  RESCUPCE  consumed  in  order  to 
carry  out  this  '’POCFSS  depends  on  the  particular  PROCESSOR 's 
ability,  which  is  expressed  in  terms  of  FFSOURCE  consumption  per 
DESOUFCF-USAGF-?A?»E  FTE° . 
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1 . 1 . 4 pr o-j“c t va  nag°  ment  Objects 

nroiect  man  =» ao.n“ nt  objects  are  used  to  provide  information  about 
thr»  individual  writing  the  UFL  description  of  the  target  system. 
UpT  is  not  intended  to  be  a project  manaqement  system,  but  it 
provider  for  types  of  objects. 


T>eonLFr-  DFFXV^F 

°FOnLFM- ORFI NrV  is  ar  object  used  *o  describe  a person  who 
writes  the  orobl“m  statement  (URL  statements)  for  the  target, 
system  or  who  has  the  responsibility  of  maintaining  the  rJRL 
•’ascriptions  for  one  or  more  other  URL  obiects.  For  example, 
nP03 LFM- PFFIK2F , "Jane  Smith,'*  may  be  responsible  for  the  URL 
description  of  the  objects,  "employee  information,"  "payroll 
Drocessi  no, " etc.,  while  other  people  on  the  project  may  be 
resnonsihle  for  o+her  obiects  in  the  tarqet  system's 
descri pt  ion . 


2AIL5CX 

A UATT.PCX  is  used  to  (’“scribe  the  location  where  questions 
and/or  information  about  the  URL  description  of  a particular 
tarqet.  system  may  be  sent.  Usually  a MAILBOX  is  related  to  a 

°FOBLF,’.“  pyyT 


1.3.F  property  Ubjecjs 

’or  an  accurate  description  of  a tarqet  system,  special 
proner'-ies  of  corMin  objects  must  be  define!.  For  example,  in 
describing  a larqe  information  processing  system,  it  may  be 
necessary  * o define  which  functions  (PPOCFS3E3)  are  to  be  done 
manually,  run  batch,  or  on-line,  etc.  The  URL  object,  types  that 
are  available  are  SYNONYM,  KEYWORD,  ATTRIBUTE,  A "'TRIBUTE -VALUE, 
CL  * 3 riFTCATIOtl , MEMO,  SOURCE,  SECU  RITt  and  T RACE- KEY  . 

3YU0JJYS 

A synonym  is  us“ i to  define  an  alternative  name  (alias)  for  a 
qlyen  name  ir  the  UR  L description  of  the  system.  The  SYNONYM 
may  simnly  defin°  an  abbreviation  cf  a long  name  or  specify  a 
totally  different  name  for  an  object*  depending  on  who  looks  at 
the  oMect  (i.e.,  several  people  may  think  of  the  same  thing, 
but  call  it  several  different  naafes)  . 


KEYWORD 

A Keyword  is  an  object  type  used  to  identify  one  or  more  objects 
in  the  target  system  description  for  selection  and  analysis 
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purposes.  For  example,  if  all  functions  (PROCESSES)  described 
as  being  manual  procedures  in  the  target  system  were  to  be 
listed  and  analyzed  together,  the  KEYWORD  "manual"  could  be 
attached  to  each  PROCESS  for  this  purpose. 


All  2Q.il  A T 0 T B UTE- V ALU E 

A ??  P T ef!T  ES  and  A TTPI  B UTE-  VALUES  are  used  to  describe 
characteristics  of  particular  objects  in  the  target  system 
description  that  may  not  be  described  by  anv  other  URL 
statements.  For  example,  to  describe  that  the  lenqth  of  an 
EL  EM  EM'"  is  six  characters  long,  the  ATTRIBUTE  "length"  could  be 
defined  and,  for  a particular  ELEMENT,  the  corresponding 
A7TF  TPUm E-VALUE  could  be  "6." 


CL  A c STpTATTON 


CL ASSTFTCA’TITON  may  be  associated  with  data  obiects,  PROCESSES 
and  pnocFSSD PS  in  the  taraet  system.  A value  may  also  be 
associated  with  the  CLASSIFICATION.  In  order  for  a PROCESS  or 
PROCESSOR  to  be  allowed  access  in  the  target  system  to  a data 
object,  it  must  have  all  the  CLASSIFICATIONS  that  are  associated 
with  the  data  object,  and  the  value  must  be  greater  than  or 
egna 1 +o  the  value  associated  with  the  data  object. 


wr  l?MO 

A MFTO  is  used  to  describe  a note  (text)  relevant  to  some  aspect 
of  *h=  target  system  description.  For  example,  a note 
concerning  unresolved  problems  in  describing  a select  number  of 
engnps  in  the  target  system  description  could  be  defined  as  a 
NEMO  and  ♦•hen  related  to  each  of  the  appropriate  GROUPS. 


SOURCE 

A SO  MFC'*'  is  used  to  describe  an  object,  outside  of  the  problem 
statement,  relevant  to  the  description  of  one  or  more  objects  in 
♦■he  ♦arget  system  description.  'or  example,  a feasibility  study 
of  the  targe'*-  system  b-^inq  designed  may  have  information 
relevant  to  why  one  alternative  of  describing  the  target  system 
was  chosen  over  another.  The  feasibility  study  could  be 
designated  as  an  object  of  type  SOURCE. 


F’CU  PT^Y 


s ecu P T-" Y is  used  ♦■o  identify  what  object  descriptions  can  he  • 
reviewed  hv  a given  class  of  persons.  Some  types  of  information 
maintained  by  the  target  system  mav  be  considered  confidential, 
so  t),P  description  in  the  problem  statement  on  how  this 
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information  is  maintained  may  be  restricted  to  high  level 
management  and  a few  select  programmers. 


"•RACE-K^Y 

1 


A Tc  ACT- FEY  is  used  to  correlate  objects  which  exist  in 
different  data  bases.  For  example,  the  logical  system  design 
and  physical  system  design  of  a security  control  system  may 
exist  in  two  different  data  bases.  An  object  called  a security 
level  may  exis*  ir  the  logical  design  data  base,  and  a field  of 
numbers  called  a security  level  number  may  exist  in  the  physical 
design  data  base.  A TRACp-KEY  called  a security  level  key  may 
be  applied  to  both  objects  to  display  the  correlation  between 
them  . 


1 • 4 URL  pela  t ion  ships 

"he  previous  section  presented  the  types  of  objects  that  must  be 
defined  when  describing  an  information  processing  system. 
Organization  objects  define  the  environment  in  which  tha  target 
system  is  embedded,  "arget  System  objects  describe  the 
components  of  the  target  system.  Project  Management  objects 
describe  the  pro iect  in  which  the  target  system  is  being 
developed,  and  Property  objects  describe  properties  of  all  types 
of  obdects. 

In  addition  to  identifying  particular  objects  (by  giving  then 
names),  the  relationships  among  these  objects  must  be  stated. 

Por  example,  if  "employee-information"  is  defined  to  be  an  INPUT 
and  "payroll-processing"  as  a PROCESS,  a relationship  connecting 
these  two  objects  may  be  specified.  in  URL  terminology,  if 
"employee-information"  is  an  input  to  "payroll-processing,"  the 
relationship  can  be  stated  "payroll-processing"  R2CEIVES 
"emplcvee-inf ormation"  or  "employee- inf omation"  is  RECE.IVED  by 
" pay  roll- pro cess ing. " 

pigure  1 . 4 presents  a listing  of  all  relationships  allowed  in 
URL  in  alphabetical  order  along  with  legal  abbreviations  for 
these  statements.  (A  dash  in  place  of  an  abbreviation 
designates  that  there  is  no  acceptable  abbreviation  for  that 
statement.)  This  section  gives  an  introduction  to  the 
relationships.  They  are  defined  in  detail  in  Section  2 and  3. 


1.4.1  Compl  ement  arit  y 

One  characteristic  of  most  relationships  between  two  names  is 
♦■hat  it  may  be  specified  in  both  directions.  For  example, 
specifying  that  an  OUTPUT  is  GFNEPATED  by  a PROCESS  is 
equivalent  to  specifying  that  the  PROCESS  GENERATES  the  OUTPUT. 
GENERATED  and  GENCRA TEE  are  called  complementary  relationships. 
Figure  1.4.1  presents  a list  of  all  complementary  relationship 
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Dairs.  (A  dash  desionates  that  the  relationship  does  not  have  a 
com n lament. ) 

7.  is.  2 P elat  jonsh  ips  Pet,  ween  Different  Classes  of  Objects 

rJPL  allows  a number  of  relationships  to  "connect”  objects 
whether  they  are  of  the  same  class  as  defined  in  Section  1.3  or 
in  different  classes.  For  instance,  in  the  above  example,  two 
""arget  Rystem  objects  were  related  via  the  RECEIVES 
relationship.  Since  Organization  objects.  Project  Management, 
and  Proper^v  ob-iects  also  contribute  to  the  description  of  the 
system,  they,  too,  must  be  related  to  defined  Target  System 
objects.  Therefore,  there  is  another  set  of  relationships  to 
connect  marget  System  objects  with  Organization  objects,  another 
for  ""arget  System  objects  and  Property  objects,  etc.  The 
possible  r,nts  of  relationships  are  shown  in  figure  1.4.2. 

Relationships  mav  be  classified  in  the  same  way  as  objects  were 
classified  in  S^ctior  1.2.  The  first  row  of  figure  1.4.3 
presents  relationships  that  an  Organization  object  may  have  with 
other  Organization  objects,  with  Target  System  objects.  Project 
Management  objects  and  Property  objects.  The  second  row 
presents  relationships  that  a Taroet  system  object  may  have  with 
Organization  objects,  other  Target  System  objects.  Project 
Management  objects  and  Property  objects.  The  third  row  presents 
relationships  that  a Project  Management  object  may  have  with 
organization  objects.  Target  System  objects,  other  Project 
Management  objects,  a nd  Property  objects.  The  fourth  row  in 
Riouro  1.4.?  presents  relationships  that  a Property  object  may 
have  with  organization  objects.  Target  System  objects.  Project 
"anaaement  objects  and  other  Property  objects. 
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Abbre- 

Abbre- 

”£l§ ii2E ship 

212*122 

Relationship 

2ia*i°2 

» PPL Tfc 

APP 

PROCEDURE 

PPCD 

ASSERT 

A SPT 

RECEIVED 

RCVD 

ASSOCIATE!) 

ASOC 

RECEIVES 

RCVS 

ASSOCIATED- DATA 

A SOD 

RELATED 

REL 

A TTp  I PUT PS 

ATT? 

FF  SOURCE- USAGE 

PU 

BETWEEN 

BTWN 

R3 SOU RCE-USAGE-PAP A METER-VALUE 

FUPV 

CARDINALITY 

CAPD 

RESPONSIBLE 

PESP 

CAUSED 

CSD 

PE  SPONSIBLE-INTERPACE 

RINT 

CAUSES 

CSS 

PP SPONSIBLE- PR OBLFS-DEFINER 

P PD 

CLASSIFICATION 

CLS 

SECURITY 

SBC 

CC'ivrC"TTI'"Y 

CONN 

SECURITY- ACCESS-RIGHTS 

SAR 

CONSISTS 

C STS 

SEE-NEMO 

SM 

CONSUMED 

CNSD 

SOURCE 

SRC 

CONSUMES 

CNSS 

SUBPARTS 

SUBP 

CONI AINFP 

CN^D 

SUBSET 

SST 

DEPENDS 

PPNS 

SUBSETS 

SS^S 

DERIVATION 

DRVN 

SUBSETTING-CRITERIA 

SSCA 

PEP  I VFP 

DPVD 

SUBSETTING-CRITEFION 

SSCN 

DFPIVES 

D?VS 

SYNONYM 

SYN 

DESC  PIP^ION 

DESC 

TERMINATED 

TRMD 

GENT"  r-  ATI  C 

GENP 

TERMINATES 

TRMS 

GENERATES 

GENS 

termination 

TERM 

HAPPENS 

HAP 

TERMINATION-CAUSES 

TERC 

ID IN  TINTED 

TDD 

TRIGGERED 

TRGD 

IDFN  T I PT 

IDS 

"•PIGGERS 

TRGS 

INCEPTION 

INCP 

UPDATED 

UPDD 

INCE  PTT0  N-CA  U3rI 

INCC 

UPDATES 

UPDS 

INTFPPUPTPD 

I JT'P 

USED 

- — 

r NTF  r PUPTS 

TNTS 

USES 

•m  mm 

fpywoP^ 

K«*Y 

UTILIZED 

UTLD 

v APE 

- - 

UTILIZES 

UTLS 

NATES 

MAK 

VALUES 

VAL 

vAIL»ry 

BOX 

VOLATILITY 

VOL 

MAIN"’ AT  MFD 

"NTD 

VOLATILITY-MEMBER 

VOLM 

MAINTAINS 

ENTS 

VO  L ATILITY-SFT 

VOLS 

MEASURE!* 

F SCD 

WHILE 

WHL 

PEAS  UPSS 

WSPS 

PANT 

- - 

BEPPOF>“,FU 

pe-p 

PERFORMS 

PPNS 

*igure  1.4 

List  of  rp»L  Statements  in  Alphabetical  Order  with  Abbreviations 
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CQlatior,shio 

RSSf.PT 
A”SOCTAT  FD 
A7TF IRUTES 

cardinality 

CAU  SFD 

CONNECTIVITY 

CONSUMED 

CONm  ATNFD 

DFPFNDS 

DERIVED 

GSNFPAT^D 

HAPPENS 

IOFN^ifTED 

TNCFPTION 

IN TF BE UP T^D 

KEYWORD 

MADE 

V.  ATIBCX 

MAINTAINED 

"FAS  U^FD 

PART 

PEP^CRM^D 

PFCE1VID 

”FLATEP 

PESO  UPCF— USA  GE 

RESPONSIBLE- INTERFACE 

PESP0NSTBLF-PF03LEE-DEFINEP 

SECURITY 

SEE- MEMO 

SOURCE 

SUBSET 

U UBS FTTT NO- CPImERIA 

SYNONYM 

TERMINATED 

TERM  TNATTON 

TRACE-KEY 

TRIGGERED 

UPDATED 

USED 

UTILIZED 

VALUES 


Compleme ntarv  uelationsh  jp 


ASSOCIATED-DATA 


CAUSES 

CONSUMES 

CONSISTS 

DERIVES 

GFNERAT*S 

IDENTIFIES 

INCEPTION-CAUSES 

INTERRUPTS 

APPLIES 

MAKES 

A ° PLIES 

MAINTAINS 

MEASURES 

SUEPAFTS 

PERFORMS 

RECEIVES 

BFTWEEN 

PESOIIRCE-US  AGE-PARAMETER- VALUE 

RESPONSIBLE 

RESPONSIBLE 

APPLIES 

APPLIES 

APPLIES 

SUBSETS 

SUBSETTING-CRITERION 

DESIGNATE 

TERMINATES 

TERMINATION-CAUSES 

APPLIES 

TRIGGERS 

UPDATES 

USES 

UTILIZES 


Figure  1.4.1 

List  of  all  UPL  Relationships  with  Complementary  Relationships 
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ORGANIZATION  OBJECTS 

TARGET  SYSTEM  OBJECTS 

opq  ANT7 ATION 

SUDPAPTS/PAFT 

GENERATES 

OB  TTCTS 

RESPONSIBLE 

RECEIVES 

GENERATED 

ASSOCIATED/ 

ASS  OCX  AT  ED-  DAT  A 

SYSTEM 

RECEIVE^ 

CARDINALITY 

OBJECT*5 

OPSPCNSTBLE-lNTEFFACE 

CAUSED/CAUSES 

CLASSIFICATION 

CONNECTIVITY 

COM  SOWED /CO  NS  UN  ES 

CONT  AINED/CONSI STS 

DEP I VED /DERIVES 

GENERATED/GENER  ATES 

HAPPENS 

IDENTIFIED/ ID EM TIDIES 
INCEPTION/ 

INCEPT  I ON- CAMS ES 
INTERFUPTED/I NTEP  RUPTS 
K A.  DE/MAKES 

WAINTAINED/MA IN  TAINS 
MEASURED/ME A SUR  ES 
PART/SUBPART 
PER  FORM ED/PEPFO RES 
PECET VED /RECEIVES 
RELATED/ PEL  ATES 
RESOURCE- OS  AGE/ 
PESOURCE-USAGE- 
PA  PANE  TER-  VALUE 
SECURITY- ACCESS -RIGHTS 
SUBSET/SUBSSTS 
SUBSETTING-  CRITERIA/ 

S UB SETTING -CP  IT EP ION 
TERMINATED/ TERM  INAT  ES 
TERMINATION/ 

T ERMINATION-C AUSES 
TRACE-KEY 

TFIGGEP  2D/TR IG5  FRS 
UPDATED /UPDATES 
UTILI7SD/UT  ILIZ  ES 
VALUES 


PROJECT 

FpS  PON ST  RLE 

responsible 

MAN  A GEMINI 

ORJprTf‘ 

ppoppp-y 

OBJECTS 

appi irs 

APPLIES 

T’iqurp  1.4.2  relationships  amonq  Classes  of  Oblects 
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PROJECT  MANAGEMENT  OBJECTS 

PROPERTY  OBJECTS 

ORGANIZATION 

OBJECTS 

RES  PON  SIBLE-PROBL  EM-DEPINER 

ATTRIBUTES 

KEYWORDS 

SECURITY 

SEE-HEMO 

SOURCE 

SYNONYM 

TRACE-KEY 

TARGET 

SYSTEM 

OBJECTS 

PPS  PONSI BLE-PROBLEH-DEFINER 

ATTRIBUTES 

KEYWORDS 

SECURITY 

SEE-HEMO 

SOURCE 

SYNONYM 

TRACE-KEY 

PROJECT 

MANAGEMENT 

OBJECTS 

MAI L BOX/ APPLIES 

ATTRIBUTES 

KEYWORDS 

SECURITY 

SEE-MEMO 

SOURCE 

SYNONYM 

TRACE-KEY 

PROPERTY 

OBJECTS 

APPLIES 

ATTRIBUTES 

KEYWORDS/APPLIES 

SECURITY/APPLIES 

SEE-MEMO/APPLIES 

SOURCE/APPLIES 

SYNONYM 

TRACE-KEY 

figure 

1.4.2  Relationships  among  Classes  of  Objects 
f Continued) 
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1.3.3  Na  r rat iv^  and  Text  Desert  ption 

Any  information  which  is  needed  to  describe  an  obiect  and  which 
cannoi  be  specified  by  using  one  or  more  relationships  can  be 
specified  in  a narrative  or  text  description  called  a comment 
entry.  Those  comment  entries  are  not  named  (as  objects  are 
name)  and,  ^"refore,  apply  to  only  one  particular  name.  A 
number  of  different  types  of  comment  entries  may  be  defined 
depending  on  the  ‘■ype  of  object  they  pertain  to.  The  types  of 
narrative  and  free-format  descriptions  that  may  be  defined  in 
UDT.  according  *o  the  class  of  objects  beina  described  is  giveq 
in  figure  1.4.3. 


1.3.4  n assi f ica  r ion  of  relationships  by  System  Aspects 

relationships  may  be  grouped  into  nine  major  groups  on  the 
basis  of  the  "aspect"  of  the  system  which  they  describe.  These 
nine  major  aspects  are: 

System  Plow 
System  Structure 
Data  S’-rncture 
Data  Derivation 
System  Size  and  Volume 
System  Dynamics 
System  Archi'-ectur e 
System  Properties 
°roject.  Management 

Each  is  defined  below.  Specifying  information  about  each  of 
these  aspects  involves  one  or  more  object  types  and 
relationships.  figure  1.4.4  presents  a summary  of  these  nine 
aspects  with  corresponding  objects  and  relationships. 


1.4. 4.1  System  g low 

"'he  System  Plow  aspect  of  the  system  deals  with  the  interaction 
between  the  target,  system  and  its  environment.  This  involves 
describing  those  objects  (INPUTS)  which  are  supplied  by  the 
environment  (INTERFACES)  to  the  target  system,  those  objects 
(OUTPUTS)  which  are  produced  by  the  target  system  and  accepted 
by  f he  environment,  and  the  responsibility  of  the  environment 
for  information  (SFTS)  within  the  system. 

»nv  transfers  of  data  within  the  system  are  not  considered  as 
uart  of  System  Plow  because  there  is  no  interaction  with  the 
envi tonment . 
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1.4.4.?  S ys t e m Structure 

tvstcm  structure  is  concerned  with  the  hierarchies  inherent  in 
most  types  of  systems.  (This  includes  intonation  structures  as 
well  as  processing  structures.)  Structures  nay  also  be 
introduced  to  facilitate  a particular  design  approach  such  as 
"ton  down."  In  this  context,  all  information  may  initially  be 
groupfd  ♦oq^ther  and  called  by  one  name  at  the  highest  level, 
and  ♦•her  gradually  broken  down.  System  structures  can  represent 
high-level  hierarchies  which  may  not  actually  exist  in  the 
sys*  eni  as  well  as  those  ♦■hat  do. 


CLASS  CF  OBJ  FC^  7YPFS  COMMENT  ENTRY  RELATIONSHIP 


ORGANIZATION  OBJ  ECTt  DESCRIPTION 


ta?g ft  s ystt;m  ob.tfcts  df^ivation 

DESCRIPTION 

PROCEDURE 

VOLATILITY 

VOLATILITY-MEMBER 

VOLATILITY-SET 

WHILE 


PROJECT  M AN  A GREEN"  DESCRIPTION 

objects 


ppepypry  OBJECTS 


descfirticn 


▼ 


pioure  1.4.3  Types  of  Comment  Entries 
for  each  Class  of  Obiects 
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SYSTEM  ASPECT 

URL  OBJECTS 

URL  RELATIONSHIPS 

SYSTEM  FLOV 

INTERFACE 

INPUT 

OUTPUT 

PROCESS 

SET 

PECFIVES/PECEI V ED* 

GENERATES/GENERATED* 

UPDATES/UPDATED* 

PE  SPON  SIRLE-INTERF ACE 

SYS^'F  STRUCTURE 

INTERFACE 

INPUT 

OUTPUT 

PROCESS 

SET 

FURSFTTING- 

CPITEFIOM 

SUPPARTS/PART  OP 

SUBSET/SUBSETS 

UTILIZES/UTILIZED* 

SUBSETTIN3-CRITERI A/ 

SU  RSETT ING-CBITERI ON 

DATA  STPUCTURS 

GROUP 

ELEMENT 

F NTITY 

PELATTON 

CLASSIFICATION 

CONSISTS/CONTAINED 
IDENTIFIES /IDENTIFIED 

CLASSIFICATION 

ASSOCIATED/ASSOCIATED-DATA 

DA""A  DFPIVATION 

INTERFACE 

INPUT 

OUT»nT 

PROCESS 

S ET 

GROUP 

ELEMENT 

ENTITY 

USES/USED 

DERIVES/DERIVED* 

UPDATE S/UP DATED* 

MAINTAI NS/M  AINT  AIN  ED* 
PROCEDURE  » 

DERIVATION  * 

SECUPITY- ACCESS- 
RIGHTS 

SYSTEM  sis? 

SYSTEM- PARAMETER 
INTERVAL 

CONSISTS 

HAPPENS 

CONNECTIVITY 

CARDINALITY 

VALUES 

VOLATILITY  » 
VOLATILITY- SET  * 
VOIATILITY-MEMBER  » 


* co»»er*:  entry 

* conditional  (DEPENDING  ON)  and  repetition  (FOB  EACH)  clauses 
are  allowed 

Figure  1.4.4 

UP L object  and  Statements  Organized  According 
to  Aspect  of  Target  Systea  Described 
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AcPTCr'  "PL  OBJECTS  UPL  PELATI ONSH I PS 


SYSTEM  DYNAMICS  FVFN'rS  CA  USES/CAUS  ED2 

CONDTTTD  N INCEPTION-CAUSES/ 

ON  INCEPTION* 

IN  TER?  UPTS  /INTERRUPTED* 
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TFRKTN  AT  ION-CAUSES/ 

ON  "’EPMINATTON* 

”P IGGZ  FS/T  F IGG  ERED ‘ 
WHILE  » 
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CONSUMFS/CONSUMFD 
PE  FORMS /PER FOR  MFD 
PE  SOURCE- US AGE/ 
SFSOnPCR-USAGE- 
PAPAME^EP- VALUE 
MEASURES /MEASURED 


PROJECT  MANAGEMENT  PROP LEM- DEFINTP  PES PONS TBL E/ 

MATT-BOX  RESPONSI BLE- 

FFORLEN-DEFINFP 

MAILBOX/APPLIES 


PROP  ER~7  ES 


ATTPIPUT F / 

ATTRIBUTE-VALUE 

KEYWORD 

MEMO 

SYNONYM. 

SOURCE 

SECURITY 

TRACF-K^Y 


ATTRIBUTES /APPLIES 
KEYWORDS/APPLIES 
SEE-MEMO/APPLIES 
SYNONYMS/DESIGNATE 
DESCRIPTION  » 
SOUFCS/APPT.IES 
SECURE T Y /A  PPT.I  F S 
"■R  ACE-KEY/APPLIES 
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* comment  entry 

* conditional  (DEPENDING  ON)  and  repetition  ('OR  EACH)  clauses 
are  allowed 


piqiire  1.4.4  (Continued) 
m?l  Ob  ieot  an  1 Statements  Organized  According 
to  Aspect,  of  Tarqet  Svst.em  Described 
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1.4.  4.1  Data  Structure 

nata  Structures  represent  the  relationships  that  exist  among 
•lata  used  and/or  manipulated  by  the  system  as  seen  by  the 
"users"  of  the  system.  Data  Structures  also  exist  in  the  way 
data  is  grouped  in  collections  of  information  such  as  documents. 
The  description  of  Data  Structures  also  involves  specification 
of  relationships  among  logical  collections  of  data  and  the  data 
associated  with  such  relationships. 


1.4. 4.4  Da*  a Per i vat i on 

The  Data  Derivation  aspect  of  the  system  description  specifies 
the  way  in  which  dat a is  manipulated  or  derived  by  the  system. 

Tt  specifies  what  information  is  used,  updated  and/or  derived, 
how  this  is  done,  and  by  which  processes.  This  aspect  differs 
from  Svstem  ^1.ow,  since  System  Flow  only  designates  the  inputs 
*o  tb  system  and  *he  end  results  (OUTPUTS)  , without  specifying 
wha*  actions  take  place  to  bring  these  transformations  about. 
Data  Derivation  can  deal  with  the  very  lowest,  transformations  of 
data,  whereas.  System  Flow  deals  with  high  level  collections  of 
information  (i.e.,  INPUTS  and  OUTPUTS). 


1.4. 4.5  System  Sire 

?h«  System  Sire  is  concerned  with  the  sire  of  the  system  and 
those  factors  that  influence  the  volume  of  processing  that  will 
be  required.  To  describe  svstem  sire,  the  parameters  involved 
are  named  as  obiects. 


1.4.  4 . t c ys t e m Dynamics 

The  dynamic  analysis  aspect  of  system  description  presents  the 
manner  in  which  the  target  system  behaves  over  time.  EVENTS  and 
CONDITIONS  arn  used  to  help  describe  when  PROCESSES  are 
performed  and  under  what  conditions. 

1.4.4. '*  Svstem  Architecture 

The  System  Architecture  aspect  deals  with  the  physical 
components  an)  structures  that  are  necessary  in  order  to  realize 
the  aiven  user  requirements. 


1.4. 4.8  Prol ect  Nana gement 

Tn  a 'Hi*  ion  *o  the  description  of  the  target  system  being 
designed,  documentation  of  the  oroup  desioning  (or  documenting) 
*he  targe*  svstem  is  needed.  This  involves  identification  of 
oersors  involved  and  their  responsibilities,  etc. 
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1 .4 . t* . o I’ronert  i as 

All  objects  (of  i particular  type)  used  to  describe  the  target 
system  have  characteristics  that  distinguish  than  from  other 
obdects  of  *he  same  type.  Therefore,  the  properties  of 
particular  oh  i^c  ts  ir  *he  system  must  he  described.  In  general, 
properties  involve  anv  description  particular  to  a given  object. 

i . 5 System  Pocumentat ion  Using  UFL /UFA 

■"he  Process  of  using  URL/URA  to  describe  an  information 
processing  system  includes  the  following  steps: 

1)  gathering  information  about  the  system. 

2)  Expressing  the  information  in  URL. 

3)  Formatting  PPL  as  required  by  UFA. 

U)  Converting  the  Problem  Statement  into  computer  processable 
form . 

5)  Entering  the  data  into  the  project  data  base, 
f)  Generating  outputs  from  the  data  base. 


1.5.1  gathering  Information  About  the  System 

"his  step  can  be  carried  out  as  with  present  manual  methods. 
However,  the  'JPT,  structure  (sections  and  statements)  can  be  used 
as  a structure  <=or  which  information  is  collected.  UFA  outputs 
can  also  be  used  as  a checklist  of  missing  information. 


1.5.2  Fxpressing  the  Information  in  URL 
The  use  of  OFL  consists  of: 

- Identifying  objects,  naming  them  and  assigning  a unique  type 
to  each. 

- Determining  the  relationships  among  the  objects. 

- Stating  appropriate  properties  for  each  object. 

Anv  information  which  cannot  be  expressed  in  this  formal  syntax 
can  be  qiven  as  text  in  comment  entries. 

1.5.3  Format  ting  DPI  as  P eg u j. r e d by  URA 

UFA  requires  only  minimal  formatting  as  described  in  Section 
1.5. 


PART  I USEP  REQUIREMENTS  LANGUAGE  MANUAL 


H61  PO/MULTICS/CPL  nSE*'"  MANUAL 


33 


1 . S . u Convert  in g * he  Pr ob lea  S ta *~e up n v into  Computer  Pro cessable 
porm 

tvip  problem  statement  can  be  read  by  UFA  from  whatever  form  of 
computer  processable  innut  is  desired.  The  usual  procedure  will 
be  t o punch  *he  problem  on  cards  or  to  enter  it  via  a terminal. 

The  data  can  be  entered  on  cards  anywhere  in  the  first  72 
columns. 

when  data  is  ent  ared  via  a terminal,  it  will  normally  first  be 
entered  into  a file. 


t.s.n  t ry  of  f^e  P at  a into  the  Project  Pat  a 3a se 

In  TcPOS  terminology,  the  description  of  a proposed  Information 
Processing  System  is  called  a Problem  Statement  in  the  sense 
that  it.  represents  a "problem"  to  be  solve!.  The  physical 
system  designer  then  has  the  problem  of  finding  the  best  system 
to  accomplish  the  reouirements  implicit  in  the  description  of 
the  proposed  Tnf orma t i on  Processing  System.  (The  proposed 
system  can  be  considered  a solution  to  an  earlier  problem, 
namely,  the  problem  of  what  outputs  are  necessary  to  satisfy  the 
"users"  needs  for  information.)  The  URA  data  base  contains  the 
problem  statement  as  it  has  been  given  up  to  that  time. 

"he  problem  statement  will  be  built  up  over  a period  of  time, 
possibly  by  a number  cf  problem  definers  working  simultaneously, 
"hr^e  aspects  of  a problem  statement,  and  its  us«  during  logical 
system  design  need  t o be  considered? 

1)  "’he  documentation  of  the  problem  statement  available  to  the 
problem  def in^r  based  on  the  URL  information  in  the  data 
base. 

2)  The  problem  statement  as  it  exists  in  the  data  base. 

■"he  data  base  contains  information  about  all  the  objects  that 
have  been  identified,  and  all  the  relationsh  i ds  among  those 
objects  that  have  been  specified.  It  also  contains  narrative 
statements  to  be  used  in  the  final  documentation.  Except  for 
*he  narrative  statements,  the  data  is  stored  in  "coded"  form  and 
not  as  a copy  of  thp  FO”  PATTED  PROBLEM  STATEMENT . 

7)  The  method  by  which  the  problem  statement  is  added  to  or 
mod  if ie  d . 

vher  the  problem  definer  wishes  to  add  to  the  data  base  or 
modify  it  in  some  way,  input  is  prepared  according  to  the  syntax 
of  U PL,  i.e. , in  t^p  same  form  as  the  FORMATTED  PROBLEM 
STATEMENT.  However,  only  new  data  or  changes  to  the  data  need 
to  be  entered.  Any  data  not  affected  by  the  input  will  remain 
unch  anae  d. 
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"he  use  of  UFL,  therefore,  differs  from  present  methods  in  two 
significant  ways:  the  inforaation  about  a proposed  systea  can  be 
entered  in  ary  order  and  only  new  data  or  changes  need  be 
en  *e  red . 


i.S.f  Genera  » in g Out  puts  from  the  Tata  Base 

f A 

At  any  tiae  problem  definers  can  obtain  outputs  bastid  on  all  or 
part  cf  *he  data  in  the  data  base.  These  outputs  would  be  used 
bv  the  problem  definers  in  their  own  work  (Data  Collection, 
Analysis,  Design,  Evaluation  or  Improvement)  or  in  conferring 
with  users  and  others,  "he  complete  statement  containing  all 
the  data  in  the  data  base  is  called  the  FORMATTED  PROBLEM 
STATEMENT.  The  other  outputs  contain  subsets  of  the  total 
documentation,  summaries,  rearrangements  and  analyses.  The  UFA 
User’s  Manual  gives  a complete  description  of  each  report 
available  to  the  problem  definer. 

Th«  POP*  ATTE D PROBLEM  STATEMENT  is  based  on  all  the  data  in  the 
data  base.  It  is  not  merely  a listing  of  the  data  that  has  been 
entered  but  includes,  in  addition  to  the  relationships 
explicitly  stated,  those  that  have  been  implied  (i.e., 
complementary  relationships).  The  FORMATTED  PROBLEM  STATEMENT 
is  ''syntactically'1  correct,  i.e.,  it  can  be  processed  by  UFA. 

In  practice  problem  definers  would  use  the  FORMATTED  PROBLEM 
STATFMEN"  in  conjunction  with  ether  reports  from  URA . 


1 . 8 User  Peg  u ire  men  t s Language ; Syntax  S tructure 

Since  UPL  is  a language  which  must  be  understood  by  a computer 
program,  (UP  A ) , it  must  have  a formal  structure,  usually 
referred  to  as  syntax.  In  this  section,  the  syntax  structure  of 
DPL  is  outline*.  A more  detailed  statement  of  the  syntax  for 
tjpl  appears  in  "User  Peguirements  language.  Language  Reference 
Manual . " » 


1.8.1  Langua ge  structure 

HR L consists  of  several  levels; 

Syntax  Le  v e_l  Uhl  Description  Con  sti  t uten  t s 

"araet  System  Description 
'TPL  Sec*  ion 
URL  Statements 

Reserved  Words,  Names,  Numbers 
cha  r meters 


1 Part  TT  of  this  document. 
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a description  at  level  consists  of  one  or  wore  units  of  the 

succfiMin  i svs+ei  description  consists  of  one  or  wore 

T1FL  sections.  i OPL  section  consists  of  one  or  sore  ORL 
statements.  "act  'fL  statement  is  formed  by  some  cowbination  of 
’’«» served  Words,  Names,  at  d/or  Numbers,  Finally,  the  Reserved 
Bor’s,  ’'aw»s  an*  Numbers  consist  of  characters  allowed  by  the 
"P T . character  s»t. 

"he  syntax  of  ‘he  constituents  at  each  level  are  define!  in  the 
rewa infer  of  this  section. 

1 . h . ? Pr  ohlem  ffjtewent  For  w at 

nT5L  is  a free-format  language  in  contrast  to  " fi  xed- f orw  a*-  " or 
"tabular."  In  oarticular,  this  means  vhat  orl  descriotions  can 
appear  anywh°re  on  ‘le  physical  medium,  such  as  punched  cards 
anl  that  within  fairly  wide  limits,  information  can  be  entered 
i"  any  order . 

"he  procram  which  "reads"  the  Problem  Description  understands  or 
decodes  the  descriotions  by  reorganizing  a delimiter  the 
semi-colon  (;)  and  Feserved  Words.  Tne  latter  are  defined  in 
1 . r« . f . 

"he  maior  advantages  of  free  format  are  that  complex  problem 
statements  can  be  made  with  relative  ease  and  the  problem 
statements  can  be  made  fairlv  concise. 

forms  car  be  designed  if  a more  structured  method  of  recording 
the  problem  statement,  is  required.  One  possible  organization  of 
♦■he  forms  is  given  in  Section  3. 

d.f.3  Target  Tvs  tom  Ident if icatjon 

Onlv  cr e o?  a lata  base  is  needed  tc  store  all  information  about, 
a given  System.  This  data  base  represents  the  up-to-date 
version  of  the  system  description.  ORA  has  facilities  for 
specifying  the  r.ama  of  the  system  being  described  on  all  reports 
generated  from  the  data  base. 


1 .6.4  PPL  .Sections 

A rJPL  description  or  Problem  Statement  consists  of  one  or  more 
O9 L sections.  "ach  section  consists  of  one  or  more  OPL 
statements.  The  first  statement  in  a section  (and  the  only 
required  one)  is  called  the  Section  Header.  A Section  Header  is 
a OPL  statement  that  identifies  a section  and  specifies: 

1)  That  the  user  lefined  nawes  given  in  the  section  header  are 
a particular  obiect  type  (e.g.,  PROCESS  or  SET,  etc.). 
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7)  7ha*  any  UPL  s!-atem^nts  (up  to  the  next  Section  Healer) 
nr^sent  some  description  about  the  naae(s)  qiven  in  the 
header  and/or  form  relationships  between  names  in  the 
header  and  othc»r  user- d ef ined  names  in  the  problem 
s a foment. 

There  are  a finite  number  of  UPL  statements  that  are  defined  as 
Section  Headers  and  are  qiven  in  Table  1.6.4. 

CO*’  DI^I  0 N TMO 

teftne  eniPUT 

r"?raAT"  PROBLEM - DEFINF® 

ITT  M ENT  PROCrES 

EN "TTY  PPOCFSSO? 

F Vp  NT  PEL A" TON 

G~oun  FESOOPCE 

IN  P rTT  FEFOtJPCE-US  AGE-PAP  AH  ETER 

IN^EP^ACE  EE1” 

TN'T'ERVBT.  TJ  NTT 

Table  ■’.6.4.  Section  Header  Statements 

*ost  ob-i»ct  tyoes  are  defined  in  sections  of  the  same  time, 
i.e.,  a opiCE^S  would  be  defined  in  the  FFOCESS  section, 
"herefore,  ther«  is  a one  to  one  correspondence  between  types  of 
objects  and  section  headers  except  that  the  followinq  tyoes  of 
objects  ar**  all  defined  in  a DEFINE  section: 

A^^P  TPrT"'E  SECURITY 

ATT  PTBUT  E-V  AI.UE  SOURCE 

CLA  PST  * I CAT  ION  ST!  RSETTI NG-CR  ITEP  ION 

KEYWORD  SYSTE.N-PAE  AMSTER 

KATL90T  "PACE-KEY 

and  a SYNONYM  is  assinned  to  an  obdect  by  a DFSIGNATE  section. 
This  distinction  between  Type  of  Object  and  Section  Header  is 
immaterial  conceptually  and  is  introduced  only  to  simplify 
enterinq  URL  information  into  the  data  base  since  all  the  Types 
of  objects  described  in  a DEFINE  section  allow  essentially  the 
same  set  of  statements. 

’or  each  tyoe  of  section  header  there  are  a finite  number  of 
, different  upj  statements  that  can  be  specified  after  it.  For 

eramole,  if  the  section  defines  a name  to  be  an  INPUT  it  may  be 
desirable  to  say  what  GENERATES  and  what  RECEIVES  the  INPUT,  but 
it  would  be  illoqical  to  sav  that  the  INPUT  MAINTAINS  other 
information.  "herefore,  there  at<>  a select  set  of  URL 
statements  that  mav  be  used  in  conjunction  with  a particular 
<J9Cf  ion  Header.  The  Section  Summaries  in  Section  3 and  in  "User 
Requirements  Lanquaqe,  Lanauaqe  Reference  Manual, present  a 
list  cf  which  npL  statements  which  can  appear  in  each  type  of 


1 Part  II  of  this  document. 
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sect i rn . 


*..*>.*  MFL 

There  are  rhre*  basic  types  of  OPL  statements: 

1)  Section  deader  statement  - This  type  of  statement  is  used 
to  defir.o  one  or  more  names  (ob-jects)  to  b°  a particular 
ohiect  type  (“.a.,  PRQCESS  or  GROUP)  as  described  above. 

7)  Pelationship  statement  - This  type  of  statement  is  used  to 
specify  relationships  between  or  among  objects.  In 
specifying  the  target  system  description,  it  is  necessary 
to  describe  which  INTERFACES  supply  which  INPUTS  to  which 
FROCESSFS,  what  data  (GROUPS  and  ELEMENTS)  are  used  by  what 
PFOCESSFS,  what  EVENTS  cause  which  PROCESSES  to  be 
triggered,  and  how  often,  etc.  For  each  type  of  object 
particular  relationships  car.  be  specified  as  outlined  in 
1.4  and  described  in  more  detail  in  Section  2 and  3.  For 
example,  a relationship  between  an  OUTPUT  and  the  PROCESS 
which  produces  the  OUTPUT  would  be  specified  by  the 
GENERATES  statement.  A PROCESS  can  GENERATE  an  OUTPUT. 
Likewise,  an  on^PUT  may  be  GENERATED  by  a PROCESS. 

3)  Comment  wnt.rv  statement  - This  type  of  statement  is  used  to 
relate  a narrative  (or  text)  description  (comment  entry)  to 
a particular  object.  Text  descriptions,  therefore,  may  be 
used  to  supplement  relationships;  this  means  that  any 
information  which  cannot  be  directly  specified  in  one  or 
more  relationships  (relationship  statements)  can  be 
presented  in  a narrative  format. 

All  URL  statements  begin  with  a reserved  word  and  ace  terminated 
bv  a semi-colon  (;)  . if  the  statement  specifies  a relationship 
(one  of  the  typos  of  statements  defined  previously)  then  the 
statement  must  also  consist  of  one  or  more  user  defined  names 
and  may  pot  respire  one  or  more  reserved  words.  Optional  words 
may  be  inserted  in  the  statements.  For  example: 

RECEIVED  BT  em ployee- pr ocess ing ; 

begins  with  the  reserved  words,  RECEIVED,  which  is  followed  by 
an  optional  word,  BY,  then  by  a user-defined  name, 
"employee-processing"  and  finally,  terminated  by  a semi-colon. 
Blanks  are  used  to  separate  words  and  names  in  the  statement. 

Any  number  of  blanks  may  be  used  where  one  blank  is  allowed. 

If  the  statement  is  a comment  entry  type  statement,  then  the 
first,  line  of  the  statement  may  only  consist  of  reserved  words 
and  the  semi-colon.  Succeeding  lines  of  the  statement  are 
interpreted  as  the  comment  entry  text  until  a semi-colon  is 
encountered.  Therefore,  a semi-colon  may  not  be  used  in  the 
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texv  cf  a comment  °ntry  statement.  For  example: 

DFSCPTPTTQV  • 

Th°  time  card  is  the  record  of  hours  an  hourly 
employee  worked  in  any  given  week.  ; 

*nv  characters,  except  the  semi-colon,  may  appear  in  the  text  of 
a comment  entry  such  as  the  period  f.)  in  this  example.  The 
comment  entrv  text  may  not  begin  on  the  same  line  as  the 
reserved  word  for  th°  statements. 

Tn  manv  statements  which  specify  relationships  among  objects,  a 
list  of  user  defined  names  may  he  given.  For  example: 

US"?:  fica-tax,  federal-tax,  state-tax; 

desinnates  tha4  4h“  names  in  the  section  header,  to  which  this 
statement  belongs,  'IFF  fica-tax,  federal-tax  and  state-tax. 
nlanks  may  be  used  or  either  side  of  the  commas  separating  the 
user  defined  names. 

Abbreviations  of  reserved  words  may  be  used  in  place  of  the  full 
reserved  word.  For  example: 

RECEIVED  BY:  employee-processing; 

may  also  be  niven  as: 

FCVD  employee-processing; 

'he  allowable  abbreviations  (which  are  also  designated  as  being 
reserved  words)  are  given  in  Appendix  D of  "The  User's 
Rpqu  iremenfs  Language,  Language  Reference  Manual."1 


1 . <5 . f ”e served  Boris  , " amos  and  Numbers 

F°.se  r ved  words  are  combinations  of  letters  and  dashes  used  to 
identify  urt  section  headers,  URL  statements  and  optional  words. 
There  is  a limited  number  of  reserved  words  as  given  by  Appendix 
R of  "Th°  User’s  teg n irement s Language,  Language  Reference 
Manual."1  »11  reserved  words  are  defined  by  the  URL/UPA  system 
and  mav  no4  be  changed  by  the  user. 

Optional  words  may  be  used  by  the  problem  definer  to  improve  the 
readability  of  the  problem  statement.  Words  like  BY,  A,  ARE, 
AND,  ®*c.  are  legal  'J?L  optional  words.  Appendix  C of  "The 
user  Feouiremerts  Language,  Language  Reference  Manual"  is  a list 
of  all  U 5L  optional  words.  In  the  following  URL  statement: 

USED  BY  employee-processing  TO  DERIVE  paycheck; 


1 °ar*  IT  of  4his  document. 
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the  words,  USED,  BY,  TO  and  DERIVE  are  URL  reserved  words. 

user  defined  names  are  any  naaes  (words)  used  in  a URL  statement 
that  are  not  DPL  reserved  words.  Restrictions  on  user  defined 
names  are  that  they  may  only  begin  with  a letter,  consist  of 
onlv  letters,  digits  and  dashes,  and  be  no  longer  than  thirty 
characters  in  length.  The  naaes  "employee- processing"  and 
"paycheck"  in  the  previous  example  are  instances  of  user  defined 
names. 

Numbers  used  in  a UP  L statement  may  only  consist  of  the  digits  0 
through  u with  no  decimal  points  plus  or  minus  siqns,  etc., 
allowed. 


1 . B . 7 rharact  er  Jet 

All  n^served  words,  names  and  numbers  must  be  composed  of 
characters  in  the  UFL  character  set.  The  attached  list  gives 
for  each  ASCII  character  a code  of  1 to  4 classifying  the 
characters  into  the  following  categories: 

Cod'*  1:  Nonprinting  operating  System  and  transmission  control 
characters  to  be  treated  as  punctuation,  but  will  always  be 
illegal. 

Cole  2:  Puncutation,  delimiters,  etc.  which  are  not  allowed  in 
names . 

Code  3;  characters  allowed  at  any  position  in  a name. 

Cole  4:  Characters  allowed  at  any  position  in  a name  after  the 
first . 

’’■her®  are  three  versions  of  this  categorization: 

1.  A ore  pane  summary. 

2.  Sorted  By  octal  representation. 

**•  Sorted  by  code,  then  by  Octal  representation. 
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£00’ 

OC  TA1 

chaf 

1 

one 

mi  1 

null  or  time  fill  char 

« 

t 

n«)i 

soh 

start  of  headinq 

1 

on  2 

st  x 

start  of  text 

i 

013 

et  x 

end  of  text  (E03) 

1 

''Ou 

no  6 

end  of  transmission  (EOT) 

1 

r 05 

enq 

enquiry  (V»U) 

1 

ons 

ack 

acknowledqe  (RU) 

1 

r\r  7 

hel 

bell 

1 

0 10 

bs 

backspace 

1 

Oil 

ht 

horizontal  tabulation  (TAB) 

1 

3 12 

If 

line  feed  (LIKE  FEED) 

1 

nil 

vt 

vertical  tabulation  (VT) 

1 

n 14 

ff 

form  feed  (*'ORK) 

1 

3 16 

cr 

carriaqe  return  (RETURN) 

1 

n 16 

so 

shift  out 

1 

ni"» 

si 

shift  in 

1 

0 20 

die 

data  link  escaoe 

1 

n 21 

del 

device  control  1 (X-ON) 

1 

n 22 

dc2 

device  control  2 (TAPE) 

1 

0 2? 

dc? 

device  control  3 (X-OPF) 

1 

0 24 

dc4 

device  control  4 (TAPE) 

1 

0 nc 

nak 

neqative  acknowledqe 

1 

* ?6 

sy  n 

synchronous  idle 

1 

3 2? 

etb 

end  of  transmission  blocks 

1 

C 30 

can 

cancel 

1 

C 31 

em 

end  of  medium 

1 

r in 

ss 

special  sequence 

1 

033 

esc 

escape 

1 

? 34 

fs 

file  separator 

1 

n 35 

qs 

qrcup  separator 

1 

036 

rs 

record  separator 

4 

0 37 

us 

unit  separator 

< 
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CODE 

OCTAL 

CHAP 

NAME 

2“ 

~040" 

so 

space  (SPACE  BAR) 

3 

? 41 

; 

exclamation  point 

2 

042 

n 

quotation  Bark 

7 

C 4 3 

» 

number  sign 

1 

•0  44 

* 

currency  symbol 

3 

045 

t 

percent 

7 

0 45 

0 

ampersand 

2 

047 

t 

apostrophe 

2 

050 

( 

openinq  parenthesis 

2 

051 

) 

closing  parenthesis 

0 

0 52 

* 

aster  isk 

4 

053 

♦ 

plus 

2 

0 54 

» 

comma 

4 

" 55 

- 

hyphen  or  minus 

4 

"56 

• 

period 

4 

057 

/ 

slant 

4 

060 

0 

zero 

4 

061 

1 

one 

4 

052 

2 

two 

4 

063 

3 

three 

4 

"64 

4 

four 

4 

065 

5 

five 

4 

0 6* 

6 

six 

4 

0 67 

7 

seven 

U 

0 70 

0 

eight 

4 

071 

0 

nine 

2 

"72 

• 

• 

colon 

2 

0 7 3 

• 

• 

semicolon 

4 

074 

< 

less  than 

2 

0T6 

•= 

equal 

4 

076 

> 

greater  than 

2 

0 77 

? 

question  mark 
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co  2" 

OCTAT 

CH££ 

JAJ1S 

' ~i~ 

"in” 

Y 

commercial  at 

3 

*01 

A 

7 

1^2 

R 

3 

10  3 

C 

1 

1*4 

n 

3 

1*5 

p 

3 

1 Of 

r> 

3 

1 07 

0 

3 

1 10 

H 

3 

111 

I 

3 

132 

I 

3 

3 13 

K 

3 

1 1U 

L 

3 

1 15 

M 

3 

1 If 

S 

3 

1 17 

0 

3 

3 2* 

p 

7 

1 21 

Q 

7 

1 22 

R 

3 

1 27 

S 

3 

3 2 a 

03 

3 

1 25 

fI 

3 

1 2 f 

V 

3 

1 .27 

V 

7 

1 3C 

X 

3 

3 31 

y 

7 

1 3? 

7. 

2 

1 33 

[ 

opening  bracket 

3 

3 34 

\ 

reverse  slant 

7 

3 35 

1 

closing  bracket 

3 

1 36 

A 

circumflex 

4 

* 37 

underline 
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COOP 

OCT  AT. 

CHAP 

NAME 

3~ 

“4?" 

\ 

grave  accent. 

3 

1 41 

a 

3 

1,4  2 

h 

7 

1 43 

c 

3 

1 44 

d 

•> 

1 4? 

(» 

3 

1 46 

f 

3 

1 47 

q 

7 

1 5r 

h 

3 

1 PI 

i 

3 

1 *2 

1 

7 

J 

1 6? 

y 

3 

1 54 

1 

7 

155 

m 

3 

1 86 

n 

■> 

1 57 

0 

3 

1 60 

D 

3 

1 67 

q 

7 

1 62 

r 

7 

1 63 

s 

3 

1 *4 

f 

3 

i 66 

u 

3 

1 66 

V 

3 

1 6"* 

w 

3 

1 7f 

X 

7 

171 

y 

3 

172 

7. 

7 

173 

f 

opening  brace 

2 

1 74 

1 

vertical  line 

3 

176 

7 

closing  brace 

2 

176 

ts* 

tilde 

1 

1 77 

'lei 

delete  (BUBOUT) 
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CODE 

OCTAL 

CHAR 

NAME 

l" 

*‘00 

nul 

null  or  time  fill  char 

1 

701 

soh 

start  of  heading 

1 

r i>o 

stx 

start  of  text 

1 

r 03 

etx 

end  of  text  (EON) 

1 

r.  At* 

eot 

end  of  transmission  (EOT) 

1 

005 

enq 

enquiry  (WRU) 

1 

006 

ack 

acknowledge  (FU) 

1 

007 

bel 

bell 

1 

0 10 

bs 

backspace 

1 

Oil 

ht 

horizontal  tabulation  (TAB) 

1 

012 

If 

line  feed  (LINE  FEED) 

1 

<>13 

vt 

vertical  tabulation  (VT) 

1 

014 

ff 

form  feed  (FORM) 

1 

015 

cr 

carriage  return  (RETURN) 

1 

016 

so 

shift  out 

1 

017 

si 

shift  in 

1 

C20 

die 

data  link  escape 

1 

021 

del 

device  control  1 (X-ON) 

1 

022 

dc2 

device  control  2 (TAPE) 

1 

023 

dc3 

device  control  3 (X-OPF) 

1 

0 24 

dc4 

device  control  4 (TAPE) 

1 

025 

nak 

negative  acknowledge 

1 

0 26 

syn 

synchronous  idle 

1 

0 27 

etb 

end  of  transmission  blocks 

1 

0 30 

can 

cancel 

1 

0 31 

ea 

end  of  medium 

1 

0 32 

ss 

special  sequence 

1 

033 

esc 

escape 

1 

0 34 

fs 

file  separator 

1 

0 35 

qs 

group  separator 

1 

0 36 

rs 

record  separator 

1 

0 37 

us 

unit  separator 

1 

177 

del 

delete  (PUBOUT) 
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CODE 


OCTAL 

CHAP 

NAME 

0 40* 

sp 

space  (SPACE  BAP) 

* 42 

n 

quotation  mark 

0 46 

r. 

ampersand 

047 

• 

apostrophe 

0 50 

( 

opening  parenthesis 

0 5’ 

) 

closing  parenthesis 

* 52 

* 

asterisk 

0 54 

9 

comma 

072 

• 

• 

colon 

0 73 

• 

• 

semicolon 

0 7S 

= 

equal 

0 77 

7 

question  mark 

1 33 

c 

opening  bracket 

1 35 

i 

closing  bracket 

1 74 

i 

vertical  line 

176 

f* 

tilde 
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CODE  0C2LI  CHAP 
3**  “CUI  ! 

3 * 4 3 # 

? ft  4 4 f 

3 f 4C  * 

3 1 30  d 

3 1«1  A 

3 1?2  3 

3 1 n 3 C 

3 ^t'■U  0 

3 10*  E 

3 1 os  F 

3 1 37  r, 

">  11^  H 

3 1 11  T 

3 112  .7 

3 11?  K 

3 114  I. 

3 1 1*3  W 

3 11*  v 

3 117  o 

3 1 20  P 

3 121  Q 

3 122  P 

3 12  3 S 

3 124 

3 12*  n 

3 1 ?P  V 

3 1 27  w 

3 1 3ft  X 

3 131  y 

3 132  t 


V AWE 

exclamation  point 
number  sian 
currency  symbol 
percent 
commercial  at 
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t 


con- 

OC^AL 

Cl 

■> 

1 34 

\ 

3 

1 36 

A 

3 

1 40 

\ 

3 

1 41 

a 

*5 

1 4? 

b 

3 

1 U? 

c 

3 

144 

rl 

3 

1 46 

3 

V U6 

f 

3 

1 47 

g 

7 

1 5^ 

h 

3 

1 51 

i 

3 

1 52 

1 

7 

1 53 

k 

3 

1 sa 

1 

3 

1 55 

n 

3 

1 5* 

n 

*5 

1 57 

o 

3 

1 60 

D 

1 ci 

a 

3 

162 

r 

3 

1 53 

s 

3 

164 

* 

3 

165 

'i 

3 

166 

V 

3 

16T 

V 

3 

1 ■»<? 

X 

3 

I'M 

y 

3 

172 

2 

2 

17  3 

f 

2 

1 “»c 

1 

NA^E 

reverse  slant 
ci  rc  u ■ fiver 
grave  accent 


openinq  brace 
closing  brace 


, 1 
i 
* 

» - 

i 

,1 

■ 

. 


, 
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COD* 

OCTAL 

CHAR 

NAME 

4 

0 5?“ 

♦ 

plus 

4 

0 55 

- 

hyphen  or  minus 

4 

056 

• 

period 

4 

0 5-» 

/ 

slant 

4 

r 60 

0 

zero 

4 

061 

1 

on  e 

4 

0 62 

2 

two 

4 

063 

3 

three 

4 

064 

4 

four 

4 

065 

5 

five 

4 

065 

6 

si  x 

4 

06^ 

7 

seven 

4 

0 70 

8 

eight 

4 

071 

0 

nine 

4 

074 

< 

less  than 

4 

0 76 

> 

great er  than 

4 

1 37 

underline 

"he  on<?  exception  to  this  is  that  any  characters  may  he  used  in 
the  text  of  a comment  entry  statement. 

l.*.4  format  Restrict  ions 

While  UFL  is  a fre*  format  languaqe,  there  are  certain 
restrictions  that  have  been  incorporated  into  the  implementation 
of  U^a  to  facilitate  entry  of  Problem  Statements. 

One  restriction  is  concerned  with  length  of  the  statement. 

Thouqh  a statement  may  extend  over  any  number  of  lines,  only  the 
first  columns  of  a card,  or  characters  in  a message  of  each 
line  »'i v b“  used.  Arything  over  this  will  be  ignored. 

"herefore,  the  statement: 

? 7C5I  V EP  BY:  employee-processing; 

may  also  be  giv^n  as; 

PFCEIVED 

BY 

• 

employee-processing 

9 

with  no  effect  on  how  this  statement  is  interpreted  by  (JRA.  The 
only  restriction  is  that  the  statement  may  onlv  he  split  where  a 
blank  is  allowed  and  not  in  the  middle  of  a reserved  word  or 
user  defined  name. 

A second  restriction  is  the  one  mentioned  above  for  comment 
entries.  The  type  of  Comment  Entry  such  as  DESCRIPTION  or 
PPOCECUPB  bus1,  appear  on  a separate  line,  followed  by  the  text 
endinn  ir  a semi-colon. 


pan 
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a thirl  restriction  is  the  usa  of  HOF  as  a special  type  of 
st  a*  enter  t that  rterigrat.es  the  end  of  a collection  of  URL 
sections  to  be  us®d  as  input  to  UFA.  ’’’h is  statement  specifies 
tha*  there  are  no  more  UFL  statements  followinq  and  that  U RA  may 
stop  processing  of  tie  UPL  statements.  The  EOF  statements  must 
he  used  whenever  UPL  statemerts  are  qiven  as  input  to  the 
INPUT- PSL  or  DELETE- PEL  commands  in  UFA. 


1 . n Comparison  of  Manual  and  Computer-Aided  Documentation  in 
Logical  Systems  Design 


I."7.  1 Cescri.pt  \ p n in  a St  rnct.ureq  T.a  n gua  ge  Compared  to  Man  ual 
IlSllJ Usin g Forms  and  charts 


A number  of  d®sirahl 
in  S action  1.1.  The 
mav  he  compared,  as 


P j-  pcr>p  t 

Mar.ua  1 

Doc umen tat  j on 


e properties  of  documentation  were  outlined  \ 

present  manual  and  computer-aided  methods 
follows: 

Compu  t or- Aided 


Documentation 


Hard  to  Mn  rt or s t. an rt 
Am  hiouous 
In  consistent 
In  ccrap let  * 

Incorrect 

''ifficult  to  Analvre 

and  Evaluate 
Ward  to  Modify 


Under  standable 
Precise 
Consi stent 
Compl  et  e 
correc  t 

Computer-Aided  Analysis 
and  Evaluation 
Compu  ter-Aided-Updating 


A more  compr ehen sivo  description  of  how  desirable 
characteristics  of  computer-aided  documentation  can  be  achieved 
is  given  in  feet  ion  5.  The  contribution  of  the  structured 
description  language  is  outlined  in  1.7.2  and  the  contribution 
of  the  outputs  available  for  TJPA  is  outlined  in  1.7.?. 


1.7.2  '"h c a d vant  age  of  a Structured  Description  Language 
mhe  maior  characteristics  of  'Jfl  for  describing  systems  are: 
Each  object  has  a unique  name. 

Each  relationship  has  a precis®  format,  i.e.  , syntax, 
only  a specified  number  of  relationships  may  exist  among 
objects  of  giv®n  types. 

Any  number  of  properties  may  be  defined  for  objects  of  a 
given  type  hut  each  property  must  he  uniquely  named. 

The  differences  between  UFL  and  the  usual  method  of 


<) 

2) 


PAP 
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documentation  with  narrative  text  and  manual  flow  charts  are 
shown  in  the  following  table: 


Narrative  031 


Object  'James 

u nlimited 

unique 

linger  of  obleevs 

u n 1 i m it  e d 

essentially  unlimited  - 
limited  only  because  nam 
must  not  be  more  than  30 
characters  and  the  first 
letter  character  must  be 
a letter 

■^Yoe  cf  objects 

not  necess- 
arily stated 

relatively  small  number 
of  explicitly  defined 
types 

p°la tion  ships 

unlimited  and 
not  necess- 
arily expli- 
citly defined 

relatively  small  number 
of  explicity  defined 
t ypes 

Pron  erti es 

unlimited  and 
not  necess- 
arily expli- 
citly defined 

unlimited  but. 
explicitly  defined 

Qu  tput  s ' v a i 1 a V 1 e f rom  TP  A 

T°A  provides  a number  of  standard  cutouts  which  can  be  used  to 
satisfy  th®  documentation  requirements  for  ailing  the: 

’rohl  p*  Oefiner  in  His  Own  Work 
Problem  Oefiner  in  Communication  with  Users 
Coordination  in  Project 
Final  Documentation 


I.T.n  Changes  in  log  ica  1 Design 

The  use  of  a computer-aided  system  allows  changes  in  the  way 
logical  design  is  carried  out.  Table  1.7.4  summarizes  the 
differences  between  the  manual  and  computer-aided  methods  and 
resulting  improvements  in  the  various  logical  system  design 
activites:  data  collection,  analysis,  design,  evaluation  and 
improvem  ent. . 
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difference  Uetween  Manual  and  Computer-Aided 
Me4-  hods 


^a*  a 

Col  1 ec*i on 

Forms  of  standard  URL  format  can  be  used 
record,  collected  data. 

to 

Analysis 

Analyses  for  correctness,  completeness  and 
consistency  of  data  are  done  when  inputting 
data  to  URA  and  on  demand  from  URA. 

Design  of 
Proposed  System 

"■hough  desiqn  is  a creative  process,  URA 
make  more  data  available  to  the  designer 
a formatted  matter. 

can 

and  in 

Eval uat ion 

UCA  generates  accurate,  standard  reports 
in  the  evaluation  process. 

to  aid 

Tmnrovem  ent 

Modification  of  the  problem  statement  is 
made  through  availability  of  data  base 
modification  commands. 

easily 

Improvement  in  Computer-Aided  Methods 


Data  Outputs  from  UPA  can  provide  a checklist  for 

Collection  deciding  what  additional  information  is  needed. 


Analysis  Use  of  the  "URA  data  base”  insures  that 

analysis  is  always  performed  on  an  up-to-date 
version  of  the  problem  statement.  As  new 
analysis  methods  are  developed,  they  can  be 
incorporated  into  UFA, 


Pesiqn  of  Use  of  the  URA  reports  allows  the  designer  to 

Proposed  System  look  at  particular  aspects  of  the  system  of 

interest.  Simple  modifications  to  the  data 
base  can  present  alternatives  in  design  . 


Evaluation  UFA  provides  some  rudimentary  facilities  for 

computing  volume  or  work  measures  from  the  data 
in  the  problem  statement.  As  additional 
L methods  are  developed,  they  can  be 

I incorporated. 


Improvement  Rather  than  "starting  from  scratch"  to 

incorporate  chanqes  in  the  problem  statement, 
improvements  can  be  made  on  the  original  URA 
data  base. 


Table  1.7.4 

Chanqes  in  Logical  Design  Procedure  and  Value  of  Change 
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7.  FROPLEM  S TAT  EMEVT  FACILITIES  R Y SYSTEM  ASPECT 


mo  accurately  a system  it  is  Rocpssary  to  describe  all 

asn<>r*s  identified  in  1.4.  The  following  sections  present  the 
'PL  objects  and  U?L  statements  that  pertain  to  each  aspect  of 
the  system  description: 

Svstem  Flow 
System  structure 
Oat  a Structure 
!>ata  tierivation 
System  Oise 
System  Dynamics 
Svstem  Architecture 
System  Properties 
nroiect  Management 

Guidelines  ara  also  provided  to  aid  the  analyst  in  describing  a 
particular  system  in  URL,  including  guidelines  tQ  help  map  the 
objects,  as  they  exist  in  the  real  world,  into  what  they  may  be 
called  in  DPI  tnrBip ologv . The  Analyzer  outputs  relevant  to 
each  aspect  oF  the  description  are  also  presented  to  aid  the 
analyst  in  making  the  description  consistent  and  complete. 

"he  explanations  of  nFL  statements  are  given  at  three  levels  of 
precision: 

"must"  - denotes  that  this  is  checked  by  'TEA  and  not  entered 
in*o  the  data  base  unless  correct.  Note  the  "must." 
does  no*  necessarily  imply  in  this  sense  that  the 
particular  statement  has  to  be  in  the  data  base. 

"can"  - denotes  *-hat.  a choice  is  available.  Each  choice 

selected  is  checked  by  UR*  and  not  entered  into  the 
da*a  base  unless  correct. 

"should"  - denotes  *hat  this  is  not  checked  by  CJPA  before  stored 
ir  *he  data  base  but  is  necessary  for  a complete 
.description  of  the  target  system.  Some  of  these 
"completeness"  checks  are  male  when  producing  UFA 
reports  and  warning  messages  are  produced.  Others 
can  t>e  made  hv  the  analyst  using  UFA  reports. 

"implies"  -denotes  *■  he  semantic  meaning  of  the  statement. 

and  "’’his  is  not.  checked  bv  UR  A nor  necessary  for  a 

"mav"  compl.e*-?  description.  Interpretation  is  to  be 

decided  t>v  the  Problem  Cefiner  and  organization. 


i 
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2 . 1 System  Boundaries  and  Input  Output  Flow 

One  Ufl  a data  base  describes  one  Information  Processing  System 
and  objects  associated  with  it.  The  description  of  a system  can 
begin  by  describing  its  boundaries.  (Identifying  the  boundary 
of  a system  is  not  always  easy;  considerations  involved  in  this 
process  are  discussed  in  o.*.)  This  section  describes  the  URL 
facilities  in  specifying  system  boundaries  and  flow  to  and  from 
the  svstem. 


2.1.1  System  Flow  Objects 


The  boundary  of  the  target  system  is  described  in  terms  of  the 
objects  which  flow  across  the  boundaries. 


INPUT  - 


OUTPUT  - 


SPT  - 


an  obiect  which  contains  data  and  flows  into  the 
target  svstem  from  an  external  object  (i.e., 

T N^ER *ACE)  to  an  internal  object,  (i.e.,  a PROCESS). 

an  object  which  contains  data  and  flows  from  the 
target  system  to  an  external  object  from  an  internal 
object  (i.e.,  a PROCESS)  to  an  external  object  (i.e., 
ar  IN TEPF  ACT)  . 

an  object  which  designates  a collection  of  data 
containers  and  is  stored  and  updated  by  an  internal 
object,  (i.e.,  PROCESS). 


TWrr  PFACE  for  R^AL- wo  FLU- ENTITY)  - an  external  object  which  can 
produce  an  INPUT,  receive  an  OUTPUT  or  be  RESPONSIBLE 
F0B  a S?’r. 


process  - an  internal  object  which  can  accent  an  INPUT  or 
produce  ar  OUTPUT  or  UPCATE  a SET. 


2.1.2  c*ystam  Flow  Relationships 

’’’he  verbs  in  the  above  definitions  tha”  are  formal  UP L 
relationships  ar°: 


SENE  FAT’rS/OENESA'”Fn  RY 

*n  I >!"■'?**  AC*  must  GENERATE  an  INPUT  or  the  INPUT  must  be 
GENFRA^FH  UY  an  I»r?pv»CE.  A PROCESS  must  GENERATE  an  OUTPUT  oc 
“he  OfrPir  must  be  GFNSP/TFD  BY  a PROCESS. 


RFCrTEFS/RECEIVEP  BY 

An  tNTIFFACE  must  RECEIVE  an  0UTPT1T  or  the  OUTPUT  must  be 
RECEIVED  BY  an  TV"’i,PFACE.  A PROCESS  can  FECEIVE  an  INPUT  or  the 
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""•JPUT  can  »-e  ^ECE’VEf'  BY  a PPOCFFS. 


tip? a T?r/nt>'>'\  -»'»n 

A oROCEFS  mus*  UopArF  a 5 ET  or  the  Sw7  must  he  U ?D AT  E D BY  a 
pprrcs. 

Conditional  actions  can  be  described  by  the  use  of  the  DEFENDING 
p*i  clause.  Also,  rnoetition  of  actions  can  be  described  by  the 
us®  of  * tn  fop  EACH  clause. 


RESPONSIBLE  FOR /3FSPQNST  BIE“ I NTEEFACF 

An  I FACE  must  ho  RESPONSIBLE  FOP  a SET.  A SET  must  have  a 
RES^NST  F>LF-  T V’ER'AC?  . 


7.1.3  System  Flow  Syntax  and  Semantics 

"h°  obiects  and  relationships  involved  in  describing  system  flow 
are  shown  pic^oriall v in  Figure  2.1.3  and  in  tabular  form  in 
""able  2.1.3.  The  direction  for  reading  the  table  is  from  the 
left  object  to  the  desired  relationship  and  then  up  to  the 
particular  ohiect. 

An  TNT2F  FACE  can  GrNFFATE  any  number  of  INPUTS,  PECEIVE  any 
number  of  OUTPUTS,  ard  be  PESPONSIFIE  for  any  number  of  SETS. 

»n  INFUT  can  b*  GENERATED  by  any  number  of  INTERFACES  (implies 
anv  cue  of  them  must  GENERATE  it)  and  be  RECEIVED  BY  more  than 
one  process  (implies  ♦hat  all  of  them  must  RECEIVE  it)  . 

A SET  may  have  a nv  number  of  RESPONSIBLE-INTERFACES  (this 
implies  that  all  ir°)  and  may  be  UPDATED  by  any  number  of 
PROCESSES  (implies  that  all  do). 

2.1.  N System  Elow  Common  Euuivalen  ts  and  Usage 

,phe  oMect-t.  vdps  and  relationships  correspond  closely  to  those 
in  common  usage  when  applied  to  an  information  processing 
system.  "*he  main  difference  involved  is  that,  in  most  manual 
documentation  methods,  the  name  INPUT  is  related  to  any  obiect 
which  is  used  by  a PROCESS  and  likewise,  an  OUTPUT  is  related  to 
any  object  which  is  derived  by  a PROCESS.  In  general,  no  effort 
is  made  to  distinguish  between  different  levels  of  data  when 
INPUTS  and  0UtP»jT^  thought  of  in  this  way. 

INPUTS  and  outputs  are  the  names  for  logical  collections  of  data 
whose  values  mav  eventually  appear  on  physical  media  which 
contain  data  values  — such  as  forms,  cards,  tapes,  messages, 
reports.  Each  individual  input  or  output  document  is  usually 
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on?  of  a number  of  instances.  The  INPUTS  and  00TPUTS  being 
described  in  "’’L  mav  have  multiple  instances.  In  URL  the 
emphasis  is  on  the  logical  definition  rather  than  the  physical 
and  hpnoe,  ► h<=  media  or  the  physical  forma*-  need  not  he 
spec  i fie  d . 

The  us°  of  PrCrTVFS  implies  that  some  physical  process  will  be 
reguired  to  receive  or  accept  the  input  "documen  t . '•  Similarly, 
GENERATES  i m plies  a process  will  be  required  in  the  implemented 
target  system  to  physically  produce  the  OUTPUT. 


i N""?1?  E’.rs  TNorjr  output  set 

PROCESS 

TNTEF.FACE 

GENERATES* 

PECEI VFS 1 

RESPON- 
SIBLE FOR 

IN  PH"" 

G ENFP ATED  1 

B Y 

RECEIVED 

OrppnT 

P £CE’T  V FI* 

B Y 

GENERA  TED 

SE™ 

RESPONSIBLE- 

I P7CP 

UPDATED* 

ppnc  FSS 

RECEIVES* 

GENERATES  * 

UPDATES* 

Table  2.1.3 

rJ P L Statements  for  System  INPUT/OU^PUT  ’'low 

* Conditional  (DSPvndhjg  ON)  and  repetition  (FOP  EACH)  clauses 
are  allowed. 
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A S"T  ran  bo  in*3rpreta/i  as  a master-f ile  or  data  base,  or  more 
broadly  to  include  very  volatile  master  files  such  as,  for 
example,  open-order  files.  UPDATF  implies  an  operation  in  which 
some  data  values  in  the  EE"  are  changed.  The  RESPON  SI  BL E FOP 
statement  carries  the  common  connotation  of  a lata  base 
"belonging"  to  some  uni*  in  the  organization. 

» "~AI-WOPin-r-tTT-y  (or  - v"? P F ACE)  is  an  ob-ject  not  part  of  the 
svs*°ra  being  described,  but  interacts  with  the  system  in  some 
wav.  Examples  are:  employees,  departments,  companies,  etc. 


2.1.  c System  EjLow  2!lti2JiiS 

The  PICT  ftp?  report  (with  "LOW  option  in  effect)  can  be  used  to 
present  the  svs*-em  flow  relationships  (RECEIVES,  GSNEPATES, 
etc.)  among  INPUTS,  OITPUTS,  INTERFACES  and  PROCESSES  in  a 
graphical  forma*. 

"he  PROCESS- INPU?/ou"prj"  report  presents  the  same  information  as 
describe*  ihovp  for  PROCESS  names,  but  in  an  alternate  format, 
"his  report  will  also  present,  any  DESCRIPTION  statements  related 
to  * h e tPOC"sg  names. 


c y s t .-3 m Flow  Tom  rl  et.ene  ss  Checks 

The  completeness  checks  that  can  be  made  for  system  flow 
completeness  arQ: 

"very  IN^ERFAC"  should  either  (i)  GENERATE  some  INPUT  or  (ii) 
"ECEIVE  some  OUTPU"  or  (iii)  be  RESPONSIBLE  for  some  SET. 

Every  IN^U"  should  bp  GENERATED  by  at.  least  one  INTEFFAEE. 

Ever v OUTPUT  should  be  RECEIVED  by  at  least  one  INTERFACE. 

pv°rv  INPUT  should  be  RECEIVED  by  at  least  one  PROCESS . 

"very  OPT^U"  should  be  GENERATED  by  at  least  one  PROCESS. 

"he  last  four  checks  can  be  made  by  using  the  DATA  PROCESS 
report . 


2.  2 System  St  rue  lure 
Def  initi  on  o.f  Struct  ure 

A number  ot  the  objects  in  the  description  of  systems  are 
related  to  each  other  by  one  ob-ject  being  a "component"  of  one 
or  mere  ether  ob -jeers  or  "belonging"  to  it  in  some  way. 
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•>aa3cns  for  5 tructure 

Structural  relationships  may  be  defined  for  one  of  two  reasons. 
Structural  relationships  are  said  to  arise  from  the  "real  world" 
if  ♦■hoy  are  part  of  the  description  cf  the  tarqet  system  and  its 
associated  objects,  i.e.,  if  they  really  exist.  Structural 
rola  * ior  shins  are  said  to  be  "definitional"  if  they  are  madp  for 
convenience  in  the  Drocess  of  describinq  the  tarqet  system  but 
do  not  exist  for  other  reasons.  Peal  world  structure  must  be 
maintained  as  part  of  the  svstei  description  but  definitional 
relationships  may  be  discarded  when  no  lonoer  needed. 

""he  description  of  structure  permits  "summarization"  of  the 
Problem  Statement  at  various  levels  of  the  structure  and, 
therefor®,  facilitates  top-down  or  bottoa-up  problem  definition 
and  approval  at  various  levels  cf  completion. 


representation  of  structure 

structural  relationships  are  usually  called  trees  or  directed 
networks  and  represented  as  shown  in  Fiqure  2.2.  The  ob  iects 
are  represented  bv  dots  called  nodes  and  the  (structure) 
relationships  bv  the  lines,  called  arcs,  connecting  the*.  Trees 
and  networks  are  "directed"  in  that  the  nodes  are  identified  by 
the  level.  For  °xainle,  A is  a hiqher  node  than  B,  C or  H . A 
node  may  have  immediate  successors  or  lower  nodes,  e.g.,  the 
immediate  successors  to  J are  3,  F and  S.  Similarly,  a node  may 
have  immediate  predecessors  or  hiqher  nodes,  e.g.,  Q has 
immediate  predecessors  N and  P. 


Structures 

A node  which  has  no  predecessors,  i.e.,  the  hiqhest  rode  is 
called  the  root  of  the  structure,  e.g.,  A and  M. 

- A tjree  or  hierarch  ical  structure  is  one  in  which  each  node 
except  the  hiqhest  node  has  one  and  only  one  immediate 
predecessor  (Figure  2.2a). 


- A directed  network  structure  is  one  in  which  each  node  except 
the  hiqhest  node  may  have  more  than  one  immediate  predecessor. 
If  the  structure  contains  no  cycles,  it  is  said  to  be  as vclic 
(piqure  2.2b)  . 


A node  which  has  no  successors  is  called  a leaf  or  a f er mina 1 
node , 


In  seme  cases,  a structure  may  contain  objects  of  different 
types.  A structure  containing  objects  of  only  one  type  is  a 
^homogeneous"  structure;  one  containing  more  than  one  type  is 
called  "non-  homo  gene  ous.  " 
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A terminal  node  may  be  assigned  to  the  highest  possible  level  or 
the  lowest  possible  level,  e.g.,  node  D may  be  regarded  as  being 
on  the  same  level  as  J or  on  the  sane  level  as  E,  F and  G. 


A 

0 


M 

0 


• • 

BO  0 C 

• • • • 

. . 0 

• • • • 

0 ? J 0 0 

• • « H • 

...  0 T 

... 

0 G 0 

t v g 


(a) 

Tree  Structure 


• • 

NO  OP 


♦ • • • 

0 0 0 Q 

. . or 


• • • • 

0 0 0 0 
R S 0 V 


(b) 

Directed  Network  Structure 


Figure  2.2 

Tree  and  Network  Structures 


S t r u cj- ur  e in  UFL 

In  UFL,  nodes  renresent.  objects  and  arcs  represent  structural 
(and  ether)  relationships.  Two  major  types  of  structural 
rela  tior  shins  arQ  available.  Data  structure  relationships 
involve  obdects  which  are  data  elements  or  combinations  of  data 
elements.  Ml  other  structure  relationships  are  called  system 
strucfurp  statements.  System  structure  statements  are  described 
in  this  section,  data  structure  statements  in  Section  2.3. 

Table  2.2  shows  Dossible  nodes,  source  of  relationship,  type  of 
structure,  lowest  unit  and  level  of  lowest  unit  for  each  type  of 
object . 
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Input 
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Input. 

SO BP A R TS/PAPT 

Tnpu  t. 

Network 

Piemen  t 

CONSISTS/CONTAINED 

Out p lit 

0 r eo? 

output 

SUBPAPTS/PART 

Output 

Network 
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CON  ST  STS /CONTAIN  ED 

Set 

N etworV 

Set 

SUBSETS/SUBSET 

Set 

Netwo  r*f 

3n  tit ies 

CONSISTS/CONTAINED 

Se* 

R etwo  rk 

I r puts/ 

CONSISTS/CONTAINFP 

Output  s 

*rnti  tv 

Network 

Groups/ 

CONSISTS/CONTAINED 

Flera  ents 

Group 

Network 

Element 

CO  NST3TS/C0NTA I NED 

Group 

network 

Element 

CONSISTS /CONTAINED 

Process 

Tree 

Process 

SD  BPARTS/PAR? 

Process 

N etwork 

Process 

UTILIZES/UTILIZED 

Processor 

Tree 

Proca  ssor 

SUBPARTS/PART 

Interval 

N otworV 

Interval 

CONSISTS/CONTAINED 

Table  2.2 

CL'.ESTFICATION  OF  STRUCTTl  RE  IN  URL 


1 A collection  of  trees,  i.e.,  arborescence,  is  oemittal 

2 Acyclic  networks 
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2.2.  1 Sys+am  structure  Objects 

”hp  following  typos  of  objects  way  belong  to  system  structures: 


IN-rypp 

IN  PH-" 
OUTPUT 
PF  OCF.SS 
PROOFS SOR 
SE  T 


2.2.?  System  -fracture  Relationships 

Sria?A°TS  AFP /PART  OP 

'"hase  statements  mav  be  used  with: 

T N T E P F ACES 

Ty  npTC 

OH T PUTS 
?P  OCR  c SES 
PP  CC'S  SOPH 

p , g . , an  INPHT  may  have  SHBPARTS  which  are  INPUTS  or  it  may  be 
PAp'r  OF  some  other  T N PTTT . 


I 


SOS  S FT  OF/SUBHpTS  S F E 

A SpT  may  be  a snBSP'"  of  some  other  SET  or  it  may  have  other 
SETS  as  SHE SETS. 


HTILI7ES /HTI LIEF  0 BY 

A PROCESS  mav  'JFTLI7F  another  FEOCESS  or  it  may  be  UTILIZED  by 
other  PROCESS'S. 


2.2.2  Sy  stem  Structure  Synta  x anti  Semantics 

The  objects  an*  relationships  involved  in  describing  system 
structure  are  shown  pictorially  ir  Figure  2.2.3  and  in  tabular 
form  in  Table  2.2.3. 


A structure  defined  by  the  SUBPARTS/PAPT  OP  statement  is  a 
homogeneous,  hierarchical  tree,  i.e.,  all  nodes  in  a structure 
must  be  of  the  same  type  and  any  object  can  be  PART  OF  only  one 
immediate  higher  node.  A node  can  have  any  number  of  SUBPARTS 
of  he  same  tyoe. 


■’’he  relationship  in  a SUBSET  OF/SUESETS  APE  must  be  homogeneous, 
i.e.,  only  SFTS  may  be  SUBSETS  of  other  SETS.  The  structure  may 
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be  a network,  i.e.,  a SET  can  be  a SUBSET  of  any  nueber  of  other 
sets . 


The  relationship  in  UTILIZED  BY/UTILIZES  must  be  hoaogeieous, 
i.e.,  only  PROCESSES  can  be  UTILIZED  by  other  PB0CESS3S.  The 
structure  mav  be  a netowrk  since  a PROCESS  can  be  UTILIZED  BY 
any  number  of  PROCESSES. 

In  general,  "subdivid ing"  an  object  through  a structure 
statement  does  not.  directly  imply  that  relationships,  of  other 
types,  which  held  for  the  object  also  hold  for  its  SUBPARTS. 
por  examnle,  sun  pose  the  problem  stateient  has  been  defined: 

INPUT  a-input; 

GEN  FRA” E”1  BY  a-rwe; 

RECEIVED  BY  a-process; 

”hen  n®w  statements  are  added: 

INPUT  a-input; 

SUBPAP7”7  ab-input , ac-input; 


PA*” 
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SOME  STP  UCT,T  R AL  RELATIONSHIPS  EXPRESSIBLE  IN  URL 
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T NT*"5  FACE  tv  PUT  OUTPUT  set  process  processor 


'rN'T'FPFACE 


D?9"’  OP 

C USOft 

A~~ 


7 N *» rJ T r A"7'  OP 

sn°PAFTS 

rm’,!>nT  °AFTS  OP 

S'JRPAPTS 


GET  SUBSETS 

APE 

SUBSETS 

OF 


PPOCPSc  UTILIZED1 

UTILIZES* 

BY 

PART  OP 
SU3PABTS 
APE 


PROCESSOR 


PART  OF 
SUBPARTS 
ARE 


Table  2.2.3 

UPL  ateipnts  for  System  Structure 

1 Conditional  (DEPENDING  ON)  and  repetition  (FOR  EACH)  clauses 
ar<>  allowed. 


The  Analvter  will  not  automatically  assume  that  ab-input  and 
ac-input  are  GENfRATED-by  a-rwe  and  RECEIVED  by  a-process.  If 
the  aralyst  wishes  to  malte  this  statement,  he  should  add  this 
information  explicitly: 

TWPU?  a b-i nput , ac-input ; 

GENERATED  BY  a-rwe; 

DECEIVED  BY  a-process; 

In  nractice  if  the  problem  had  been  defined  from  the  top-down, 
the  anal vst  should  also  have  subdivided  the  INTERFACE  and  the 
PROCESS  when  the  input  was  subdivided. 
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2.2.4  System  Structure  Common  Equivalents  and  Usage 

"he  tree  structure  of  INTERFACES  corresponds  to  the  hierarchical 
structure  of  most  organizations.  The  tree  structure  of  INPUTS 
and  OUTPUTS  in  used  for  convenience  in  definition. 


Tt.  mav  also  he  used  to  describe: 


a)  A form  with  many  copies, 

INPU"":  FOPM-A; 

SnpP:  FORE- A-C0PY1, 
RORf.-  A-C0PY2; 

or 

b)  Document  that  is  generate 

e.g. , 

OUTPUT:  FQPr-A; 

SUPP:  EOPN- A-DEPT-  X, 

ROFT- A-DFPT-Y, 
FORM-  A-DEPm-7. ; 


• g • , 


and  goes  to  different  places. 


(names  chosen  according 
to  purpose  of  carrier 
or  final  destination) 


A PROCESS  has  ♦■wo  types  of  structures.  The  one  developed  bv 
using  SU  3PAPTF/PAF'r  OF  mav  be  used  for  top-down  definition  of 
the  system.  It  mav  also  he  used  to  represent  the  structure  of 
modules  in  a program  (e.g.,  BLOCKS  and  PROCEDURES  in  a PL/1 
program).  In  both  cases,  a tree  structure  is  appropriate. 

"he  structure  of  PROCESSES  developed  using  the  UTILIZED/’JT  ILIZES 
mav  he  used  to  represent  "calls”  to  program  or  a PROCESS  which 
is  used  (i.e.,  called  from)  in  a number  of  processing  sequences. 


2.2.S  System  Structure  F e po r t s 

"he  "70PF  A^EO  propLEE  STATEMENT  shows  the  immediate  structure  in 
which  an  ob-j^c*  is  involved,  i.e.,  all  those  objects  of  which  it 
is  PAP"'  OR,  S UU?  ET  OF  or  UTILIZED  BY  and  those  that  are  its 
RUPPAR^S,  5 n BSE? S or  it  UTILIZES. 

"h°  PICTrrr  report  (with  the  STRUCTURE  option  in  effect) 
nr^s^nts  the  SUPPORT? /PART  OF  relationships  for  INPUTS,  OUTPUTS, 
ir,?!cFtCrS  ini  PROCESSES  in  a graphical  format  of  the  immediate 
structure  of  a particular  ohjec*-. 

""h0  STRUCTURE  report  presents  the  same  information  but  in  a list 
format  which  displays  all  levels  in  the  system  structure.  (The 
reports  listed  above  only  presents  the  structure  levels  directly 
above  and  directly  below  the  designated  object..)  Loops  in  the 
system  structure  are  detected  by  this  report. 

The  STRUCTURE  report  presents  only  PART  OF/SUBPAPTS 
relationships.  U-TL  7 ZI  S/UTILIZED  BY  and  SUBSET  OP/SUBSFTS  OP  is 
only  shown  in  ♦he  FC1RMATTFD  PROBLE*  STATEMENT. 
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’.2.*  stem  Ilructur£  Completeness  checks 

All  the  counlolqnoss  statements  in  System  ''low  apply  to  each 
SUBPAPT  as  it  is  define!. 

each  subdivision,  the  totality  of  statements  about  th  “ 
F'i»?A'Tc  must  consistent  with  the  statement  about  the  obiects 
to  which  th a helono. 

a structure  of  I "TR  RACrS , since  it  represents  ‘•he  real  world, 
cannot  he  che^el  for  completeness,  i.e.  , whether  the  lowest 
level  nodes  have  been  defined,  unless  terminal  nodes  are 
designated  by  an  ’pnronria‘3  ATTRIBUTE. 

A structure  involving  TNPTlTS/QUTPUTS  is  not  homogeneous  since 
♦•he  lower  nodes  represent  GROUP  or  ELEMENTS.  The  following 
rules  should  be  observed: 

1)  All  TNnUT  structures  having  FUBPARTS  should  terminate  in 
INrUms  which  have  a media  ATTRIBUTE  (whose  value  can  be  "T3 
BE  PET" 15 Ml v 'D, " TBD)  and  which  contain  data  values. 

2)  An  INPU~  should  not  have  both  a SUB  PART  statement  and 
CCV"*AT*Je'  statement.  Only  th°  lowest  level  INPUT  should 
CONTAIN  ELr  M?NT  S . 

’I  All  OUTPUT  structures  having  SUBPAFIS  should  terminate  in 
OTTTPfJTB  which  have  a media  ATTRIBUTE  (whose  value  can  be 
"TO  RE  DF^E  REINED,  " TBD)  and  which  contain  data  values. 

U)  An  OUTPP""  should  not  have  both  a SfJBPAPT  statement  and  a 
CONTAINS  statement.  Only  the  lowest  level  cn,ri,UT  should 
CONTAIN  FI.EM’NTS. 

“her  a PROCESS  structure  is  defined  using  PARTS  OP/SUBPARTS  ARE 
each  PROCESS  mav  contain  SUDPAPTS  as  well  as  some  PROCEDURE 
statement.  A ?oocpSS  which  the  analyst  does  not  wish  to 
subdivide  further  should  be  designated  a terminal  PFOCESS  by  the 
us®  of  an  A TTPIP ,J~’r  statement. 

A PrOCESS  vhich  doec  not  have  any  SUBPARTS,  should  have  a 
ppocvrupv  statement . 


2. 3 Data  structure 

As  was  described  in  Section  2.2,  various  structural 
relationships  can  be  specified  in  URL  to  relate  "components"  of 
the  system.  when  the  structual  relationships  being  specified 
are  applicable  to  data  obiects,  the  structures  presented  are 
termed  "data  structures." 
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2.3.1  natj  " t me  t ure  Objects 
2.3.  1.1  Data  Def  jp.i»  ion 


The  tasic  objects  for  defining  data  are  ELEMENTS  and  GROUPS. 


An  ft.EMEIJ?  is  the  basic  urit  of  information  and,  therefore, 
canno*  be  subdivided.  An  ELEMENT  is  used  to  define  ar.  object 
which  may  tak®  on  a value.  For  exanulp,  if  ''employee 
information”  was  defined  to  be  an  ENTITY,  it  would  not,  in 
its°lf,  have  a value.  The  ELEMENTS  makinq  up  "employee 
information”  such  as  "age,"  "sex,"  "salary,"  etc.,  miqht  have 
values  for  a particular  instance  of  "employee  information." 


i 


i 


GROUP 

A GpnnF  is  used  to  define  a collection  of  ELEMENTS  and/or  other 
GROUPS.  This  is  done  so  that  the  information  names  can  be 
thouqht  to  be  related  within  the  larger  collection  of 
information  (INPUTS,  OUTPUTS  or  ENTITIES).  The  name  of  the 
GPOU c can  b®  thouciht  to  be  synonymous  with  the  names  of  the 
GROUP'S  components.  Ir.  the  example  of  "employee  information," 
the  "nam°"  of  the  employee  may  be  defined  as  a 3P0UP  where  the 
constituents  of  the  GROUP,  "first  name,"  "middle  initial," 
"surname"  raav  be  defined  as  ELEMENTS.  The  use  of  GROUPS  is 
primarily  a notit.ional  convenience. 


2.3. 1.2  Definition  of  Collgc tions  of  Data  Values 

The  definition  of  an  ELEMENT  or  a GPOUP  is  like  a definition  of 
a word  in  a dictionary.  The  definition  specifies  how  a word  is 
to  he  used  but  does  not  give  the  instances  of  its  use  in  books, 
paragraphs,  sentences,  etc. 

In  describing  information  systems,  it  is  necessary  to  have  types 
of  oblects  which  can  represent  the  things  in  which,  or  on  which, 
instances  (values)  qf  ELEMENTS  appear.  In  URL,  there  are  three 
such  types  of  objects:  INPUTS,  OUTPUTS  and  ENTITIES.  The 
difference  amone  these  types  of  collections  is  related  to  their 
role  in  the  taraet  system. 


INPUTS 


An  INPUT  is  a collection  of  information  produced  external  to  the 
tarqet.  system,  but  used  by  the  target  system.  For  example,  in 
an  inventory  system,  a customer  order  may  be  considered  an  INPUT 
to  the  system. 
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OTTPCl? 

An  'W'PU?  is  a collection  of  information  produced  hv  the  target 
svstem,  hut  which  is  used  external  to  the  system.  For  example, 
♦■he  pavcher*s  proiuce!  bv  a payroll  processing  system  could  be 
thought  of  as  OUTPUTS  as  they  are  eventually  used  by  employees 
outside  of  ♦ka  system.  Once  the  collection  has  left  the  system, 
no  further  reference  may  be  made  to  it. 


*n  F w 7 T Y is  a collection  of  information  which  is  maintained 
internal  to  the  system.  ENTITIES  are  initially  "produce!"  and 
-her  "maintain el"  using  information  from  INPUTS  and  then  OUTPUTS 
are  produced  using  information  from  ENTITIES  (and  other 
sources)  . The  "employee  information"  mentioned  above  would  be 
defined  as  an  T’N7TTY. 


2.3.  1.1  fej-at  ion  shies  £aong  Collections  of  Information 

Collections  of  information  maintained  internal  to  the  system 
(E vt !TTE S)  are  ofren  "related"  to  each  other  in  that  there  is 
information  which  is  not  inherent  to  either,  but  associated  with 
both.  Tn  the  example  of  a warehouse  stock  control  system, 
information  about  inventory  items  may  be  related  to  information 
about  their  suppliers,  e*c.  RELATIONS  are  used  to  describe 
these  logical  connections  among  ENTITIES. 


2 . ’ . 2 Data  structure  He  la  tigp  sh^jas 

"’h 3 relationships  that  can  be  specified  for  data  structure  are 
shown  in  tabluar  forms  in  "able  2.3.2  and  Table  2. 3. 2.1.  This 
information  is  also  presented  in  Figure  2.1.2  in  a graphical 
format. 
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CONS  I ST  0? /CONTAIN?!)  IN 

A S FT  nay  CONSIST  of  ENTITIES,  or  INPUTS,  or  OUTPUTS.  Likewise, 
an  INPUT  or~an-OUTPUT  or  an  ENTITY  say  be  CO  NT  AIN. ED  in  a SET. 


RELATED  TO  VI A/B  E^WFEN 

An  ENTITY  nay  be  PFL ATED  to  another  ENTITY  VIA  a given  B ELATION. 
A RELATION  nay  be  defined  to  exist  BETWEEN  two  ENTITIES. 


SUBSETTING-CFITERIA/SUFSETTING-CRITEPION 

A GROU"  or  ELEMENT  nay  be  SUBSETTING-CRITERION  for  a SET  and  a 
SFT  nay  have  CROUPS  and/or  ELEMENTS  which  are 
SUE  SETTING- CRITERIA  . 


IDENTIFIED  BY/IDENTIFIFS 

An  ENTITY  nay  be  IDENTIFIED  BY  a GROUP  and/or  ELEMENT  an  d a 
GROUP  or  ELEMENT  IDENTIFIES  an  ENTITY. 


ASSOCIA^ED-PA^A/ ASSOCIATED  WITH 

A RELATION  nav  have  GROUPS  and/or  ELEMENTS  as  ASi.2SIAI.EBr2  • 
Also,  a GROUP  or  ELEMENT  nay  be  ASSOCIATED  «I£B  a RELATION . 


VALUE  IS 

An  ELEMENT  mav  have  a particular  VALUE  or  range  of  VALUE  5 
associated  with  it. 

CLASSIFICATION  - A data  object  nay  have  a CLASSIFICATION. 


2.3.3  Data  Structure  Syntax  and  Semantics 

A S Y STEM— PA° A MET  2P  or  numerical  value  nay  be  specified  in  the 
CONSISTS  statement  for  SETS,  INPUTS,  OUTPUTS,  ENTITIES  and 
GROUPS  to  denote  the  number  of  instances  of  the  conponen ts  for  a 
given  instance  of  the  containing  object. 

An  * NTIT Y,  INPUT  or  OUTPUT  nay  CONSIST  of  any  number  of  GROUPS 
and/or  ELEMENTS. 

A SFT  may  CONSIST  of  any  number  of  INPUTS,  OUTPUTS,  or  ENTITIES, 
but  not  a combination  of  these  object  types.  Also,  a SET  may 
have  any  number  of  GROUPS  and/or  FLEMENTS  as 
SUBSETTING-CF  TTERIA . 
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An  "NTT^Y  cm  bp  IDENTIFIED  by  any  number  of  GROUPS  and/or 
ELEMENTS,  and  be  RELATED  to  any  number  of  ENTITIES.  However, 
for  each  unique  oair  of  ENTITIES,  a unique  RELATION  must  be 
defined.  E.g.,  if  a RELATION  between  El  and  E2  is  defined  as 
?l,  a °E  L A^IO  N between  E*  and  F?  cannot  also  be  called  PI. 

A RFIATTr»N  mav  only  be  define!  to  be  PRTWEEN  a single  pair  of 
ENTTtifs.  \ different  RELATION  must  he  defined  for  each  ENTITY 
pair.  A RELATION  m.av  have  any  number  of  G°OUPS  and/or  FLEMENTS 
as  S FSOC TATED-DA TA . 

» GROUP  mav  be  CONTAINED  in  any  number  of  GROUPS,  ENTITIES, 
TN°fJTF  and/or  OUTPUTS.  A GROUP  may  also  IDENTIFY  any  number  of 
TN""I  TIE  S , STIP  sr-Ti  NG-CFITF3I0N  for  any  number  of  SETS  and  be 

ASSOCIATED  w ITH  anv  number  of  FELATIONS.  In  addition,  a GROUP 
mav  CON SIS"  of  anv  number  of  GROUPS  and/or  ELEMENTS. 


INPUTS  OUTPUTS 

ENTITY  GROUPS 

ELEMENTS 

I N P Un  3 

SMTP  UTS 

CONTAINED 

IN 

CONTAINED 

IN 

CONSISTS 

ou 

CONS ISTS 
OF 

CONSISTS 

OP 

CON  SISTS 
OF 

e*'"  CONSISTS  COV  FIST? 

lv  o r 

r \7T TI ^S 

CONTAINED 

IN 

CONSISTS 

OF 

CONSISTS 

OP 

CON  SISTS 
OF 

GROUPS  CONTAIN-  CONTAIN- 
ED T'J  ?D  11 

EL  3m  FNT3 

CON"  A I’T-  C^N^AIN- 
F"  IN  ED  IN 

CONTAIN-  CONSISTS  CONSISTS 
ED  IN  OF  OF 

CONTAINED 

IN 

CONTAIN-  CONTAIN- 
ED IN  ED  IN 

Table  2. 

3.2 

URL  Statements  for  Data  STRUCTURE  Relationships 
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55  v* 

ENTITY 

PFIATICN 

GROUPS 

ELEMENTS 

SE" 

SUBS  ETTING- 

3U  BSET- 

CRITERIA 

TING 

CP  IBERIA 

r'N""r  TTpo 

F FI.  A TED  TO 

R/ VI  A 

IDENTIFIED 

IDENTI- 

BY 

PIED  BY 

DVT \ TIPU 

BETWEEN 

ASSOCIATED- 

ASSOC- 

DATA 

IATEO 

DATA 

r.wonrs  sues  ettt  ng- 

IDENTIFIES 

ASSOCIATED 

QP  TQM 

KITH 

? v E ? rJP~  I M r> 

IDENTIFIES 

ASSOCIATED 

VALUES 

TFT T^p  ™N 

WITH 

Table  2. 3.  2.1 

UR  L Ip  f init  ional  Statements  Pelating 
E N TT I S S , RELATIONS  , GROUPS  and  ELEMENTS 

»n  F LF  f'®'  VT  nay  be  CONTAINED  in  anv  number  of  GROUPS,  ENTITIES, 
INPUTS,  and/or  OUTPUTS.  Ar.  ELEMENT  may  also  be  used  to  IDENTIFY 
anv  number  of  rN TITI F S , be  SU3SET"ING-CPITERTON  for  any  number 
of  *EmS,  and  be  ASSOCIATED  WITH  any  number  of  RELATIONS.  In 
addition,  an  ELEMENT  ®av  take  on  a particular  numerical  VALUE  or 
a range  o^  VALUES. 


2, 3. U Da ta  Structure  Common  Equivalents  and  Usaq? 

The  names  gel  uses  to  define  data  structures  are  very  close  to 
most  terminolouv  in  this  field.  For  example,  ELEMENTS  are  often 
referred  to  as  "items,”  "data  items,"  or  "fields"  in  other  data 
structure  ♦■ermin  olog  ies.  GROUPS  are  sometimes  referred  to  as 
"segments"  or  "data  aggregates."  ENTITIES  are  sometimes  called 
"records"  and  SETS  sometimes  "files"  or  "data  bases." 

If  a SET  is  intended  to  represent  a "file"  where  ENTITIES  are 
"records,"  the  followirq  options  are  available  in  describinq  the 
file  structure. 


*) 


If  th«  ST"  cr‘Ne?IS’T,3  of  only  ore  type  of  ENTITY,  than: 


- ENTITY  occurrences  within  the  SET  may  be  ordered  and  so  a 
RFLATION  to  represent  this  ordering  may  be  defined.1 

- t'T'ITY  occurrences  within  the  SET  may  not  be  ordarad.  A 


1 If  more  than  one  RELA^ION^  is  to  be  defined  for  ENTITIES  within 
a given  SET,  a SET  (which  ifc  a SUBSET  of  the  given  SET)  should 
be  defined  for  each  RELATIOf(. 

I 

I 
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RELATION  to  represent  this  need  not  be  defined. 

- ENTITY  occurrences  nay  be  RFLATED  to  each  other  based  on 
some  criteria.  A RELATION  should  be  defined  to  describe 

this  relationship* 

b)  If  the  S*T  CONSIST  of  more  than  one  type  of  ENTITY: 

- FNII-"!  occurrences  nay  be  ordered.  A RELATION  should  be 
defined  for  each  ordering.  * 

- ENTITY  occurrences  may  not  be  ordered. 

- ENTITY  occurrences  may  be  PEL ATSD  to  other  ENTITY  types 
(for  each  oth°r)  . A FELATTON  should  be  defined  to  describe 
each  of  these  relationships. 

The  TDEN  TIFT  PS  statement  for  GROUPS  or  ELEMENTS  may  be  used  to 
define  keys.  It  is  meant  that  the  designated  GROUP  or  ELEMENT 
mav  be  used  when  searching  for  a particular  ENTITY  (record) 
occurren  ce. 


HOW  TO  USE  THE  RELATION  SECTION 
TC  EXPRESS  LOGICAL  CONNECTION  IN  PROBLEM  STATEMENT 


St  e£  1 

a) 


h) 


Tetermir.®  symbolic  (UFL)  name  for  the  RELATION.  It  is 
recommended  that  the  name  denotes  the  type  of  connection 
that  it  will  supply. 

Peter-nine  which  ENTITIES  the  FETATION  connects  and  the 
direction  of  the  connection.  Use  the  URL  BETWEEN  and 
CON NFCT I 71? Y statements  to  state  this  information. 


’xanDle: 

euoDos°  the  analyst  has  the  following  (logical)  view  of  his 
data  : 


J 
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♦ 


♦ 


T I 
T I 
I DEDAF'"MENT  I 


I 


♦ 


♦ 


T HOURLY  T 
I EMPLOYE'S  I 
T T 

---------- + 


-♦ 

I I 

I SALAFISD  I 
I EMPLOYEES  I 
T I 

-♦ 


Th»  met,  statements  that  define  the  two  RELATIONS  are: 

pv  l ATI  ON  d ep*  - to-h  our  ly-em  ployees; 

BETWFEN  dent  ANT  h ourly-em oloyees ; 

CPVNECTIVI?Y  IS  i -o  max- dept- hourly- employment ; 

RELATION  dent -to-salaried -employees; 

d®n*  A NO  3 a lari  ed- employees; 

COFNFCTIVITY  IS  1 TO  ia x-1  e p t-sa la ried-erap loym ent ; 

1122  l 

a)  De*  ermine  if  any  data  has  been  defined  to  be  CONTAINED  in 
both  ENTITIES.  Analyze  this  data  and  determine  ENTITIES  or 
ASSOCIATED  Da^A  s*  at ement  s . 

b)  Determine  if  ary  additional  data  is  needed  to  describe  the 
RELATION  and,  if  so,  this  data  should  be  defined  as 
ASSOCIATED  DATA  . 
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Sample; 

A mere  refine-1  and  detailed  logical  view  of  the  data  qiven  above 
might  be: 


♦  f 

T I 

I I 

I DEPARTMENT  I 
I I 

I T 

♦  — ♦ 


+ 

I last  date 

•T 

T 

4- 

I last  date 

I 

Iemplove?  hiredl 

Iemployee  hiredl 

lor  terminated 

I 

lor 

terminated 

I 

* 

• 

• 

• 

• 

I 

I 

I 

hourly  i 

I 

SALARIED 

I 

EMPLOYEE*;  I 

I 

EMPLOYEES 

I 

I 

I 

4 

T 

Step  2 

a)  Determine  the  PTLA^ION's  CARDINALITY 

b)  Determine  the  PFOCESRES  that  utilize  the  RELATION  and  those 
PROCESSES  that  add,  delete  or  modify  the  connection 
occurrences  of  the  P ELATION . 


Results: 

The  analyst  has  information  that  is  required  for  physical 
design.  ""here  is  a connection  between  the  programming 
requirement  an*  th»  data  base.  The  data  base  may  have  to  be 
revisel  to  be  receptive  to  the  processing  restrictions. 

Por  an  example,  see  RELATION  Definition  Pori. 
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2. 3. c Data  Structure  Outputs 

"he  CCNSTS""?  COMPARISON  REPORT  presents  the  lowest  level  data 
objects  (usually  RIV’N^NTS)  in  the  data  structure  of  the  data 
objects  used  as  input  to  *he  report.  This  information  is 
presented  in  m*ri*  form  with  several  redundancy  and 
completeness  check  diagnostics  in  a summary. 

The  CONSISTS  matrix  FFPOFT  presents  data  structure  at  a given 
level  relative  ♦ o the-  data  objects  used  as  input  to  the  report. 
uor  example,  if  an  ENTITY  name  is  used  as  input  to  the  report 
and  the  CONSISTS  parameter  is  specified,  all  GROUPS  and/or 
EL'MFtrS  the  ENT I IT  crvsISTS  of  will  be  presented.  If  the 
FNTTTY  name  and  the  CONTAINED  parameter  is  specified,  ail  those 
SETS  vhe  ENT T TY  is  CONTAINED  will  be  presented.  All  information 
in  the  report  is  presented  in  a matrix  format. 

The  CONTENT*5  ?F°ORT  presents  the  data  structure  at  all  levels 
for  a given  data  object  as  input  t.c  the  report.  The  CONTENTS 
rEPon"  presents  the  data  structure  going  down  to  the  lowest 
specified  in  the  nrotierj  statement. 

"The  IDENTIFIER  INFORMATION  RFPORT  presents  those  ELEMENTS  and/or 
OPOMFS  defined  as  jOEtriFTEPS  for  a particular  ENTITY  or 
Presents  the  'NTITirES  TDEN"’  IFIFD  by  a particular  GROUP  or 
FLTMFNT.  '’’his  information  is  presented  in  a matrix  format. 

"he  four  reports  are  summarized  in  Table  2.3.5. 
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CON  S I STf 


COMP  APT  PON 

CONTENTS 

CONST 

STS  MATRIX 

PPS 

CONSIST 

CONTAINED 

r vr* 

X 

X 

NO 

X 

t y 

X 

X 

X 

X 

INPUT 

V 

X 

X 

X 

rrr"p  nT 

X 

X 

X 

X 

G«OU  P 

Y 

X 

X 

X 

T'LEMEN"' 

X 

X 

ROW  ID 

HIGHEST 

LpV-L 

ID 

CCL 

ID 

POW 

ID 

OBJECT 

LOWEST 

NODE  C 

NEST 

HI GHER 

NODE 

0 

f • • • 

1 

i • • 

. LOWEF 

i 

1 

• 

NODE  1 

1 0 . 

. NODE 

\ 

1 

• 

1 

1 c 

♦ 

i 

1 

0 

1 

( • • 

• 

i 

1 

• 

1 

| 

• • 

i 

1 

• 

* ^ • • 

• • 

* • ® ** 

0 D 

0 

n 

0 

"ABL*  2.3.5 


2.3.6  Data  Structure  Couplet  eness  Chocks 

!11.  SITE  should  "eventually  " consist  of  INPUTS,  OUTPUTS  or 
’NETTIES  . 

Ml  INPUT*7  at  the  lowest  level  should  consist  of  GROUPS  and 
rL  EM  FN*"? . Any  GROUPS  should  be  reducible  to  ELEMENTS. 

ATI  OUTPUTS  at  the  lowest  level  should  consist  of  GROUPS  and 
ELEMENTS.  Any  GROUPS  should  be  reducible  to  ELEMENTS . 


2 . 4 Data  o^r ivat i on 

An  information  processing  system  exists  to  orocess  data,  i.e., 
to  nroduce  values  of  data  elements,  or  groups  of  data  elements, 
from  values  of  other  data  elements  or  croups.  This 
transformation  is  known  by  different  names  such  as  process, 
procedure,  function,  operation,  activity,  etc.  In  URL  the  term 

PROCESS  is  used. 

The  term  "data  derivation”  includes  the  actions  of  USING, 

ttpt) b ^ TNG  and  DEPTVTNG  data  oblects.  The  data  ohiects  that  are 
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involved  can  he  INPUTS,  OUTPUTS,  SETS,  ENTITIES,  GROUPS  and 
ELEMENT? . 


2.4.1  Data  Derivation  0 Meets 

"he  ob-jects  involved  in  data  derivation  are: 

PROCESS 

SFT 

TN  PUT 

onTFn"- 

ENTITY 

group 

ELEMENT 

RELATION 


2.4.2  Pa ta  Derivation  Relationships 

USES/OSED  - A PROCESS  nay  JJSE  a SET,  INPUT,  ENTITY, 

GROUP  or  ELEMENT.  Likewise,  a SET, 

INPUT,  ENTITY,  GPOU^  or  ELEMENT  nay  be 
USED  by  a PROCESS. 

UPDA^ES/OPDATEO  - A PROCESS  aay  UPDATE  a SET,  ENTITY, 

GROUP  or  ELEMENT,  and  a SET,  ENTITY, 

GROUP  or  ELEMENT  aay  be  UPD^IED  by  a 
PROCESS. 


DER IVFS/DPPI VED  - A PROCESS  Bay  DERIVE  a SET,  OUTPUT, 

ENTITY,  GROUP  or  ELEMENT,  and  a SET, 
OUTPnT,  ENTITY,  GROUP  or  ELEMENT  may  be 
DERIVED  by  a PROCESS. 

MAINTAINS /MAI NT MINED  - A PROCESS  aay  MAINTAIN  a RELATION,  and 

a RELATION  aay  be  MAINTAINED  by  a 
PROCESS. 


PROCFDUFF  - A PROCESS  aay  have  a PROCEpURE 

associated  with  it.  The  PROCEDURE  is  a 
consent  entry  and  nay  consist  of  any 
t ext . 


DERIVATION  - A RELATION  or  SET  Bay  have  a DERIVATION 

associated  with  it  in  the  fora  of  a 
coaaent  entry. 
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2.4.?  Data  ^privation  Syntax  and  Semantics 

"h0  objects  and  r°d  a t ionships  involve-!  in  describing  "data 
derivation"  ar<=>  shown  pictorially  in  Figure  2.4.3  and  in  tabular 
form  in  ""able  2.4.3.  "able  2.4.3.  1 shows  how  the  different 
tyn°s  of  objects  can  appear  in  the  data  derivation  statements. 
Table  2.4.?.  2 contrasts  •■ho  syntax  and  semantics  of  the  System 
'’low  Statements  (F:rIVES  and  GENERATES)  with  that  of  the  data 
derivation  st  at  r>men*‘  s . 

whenever  TNPrjc>  o'p-nr”,  ENTITY  or  SET  are  used  in  a data 
derivation  statement,  these  objects  are  interpreted  to  mean  the 
data  valuos  contained  in  *-hem. 

T '>ROCT'ct'  nay  22.3  ^n  y number  of  INPUTS,  SETS , ENTITIES,  GROUPS 
an!  ElEEENTS.  An  optional  UPDATE  or  DERIVE  clause  can  be  used 
in  conjunction  wi*t  the  use  statement  in  the  following  manner: 

f’SES  El  TO  DERIVE  P2: 


where  r?  i«*  anv  number  of  data  obdect.s  that  can  be  DERIVED  by  a 
°POC  ESF . 


a nFOCE?c  ran  UPDATE  anv  number  of  SEmS,  ENTITIES,  GROUPS  and 
FLEE EP^S . An  optional  USING  clause  can  be  used  in  conjunction 
with  the  gp u a t statement  ir.  the  following  manner: 

UPDATES  El  USING  F2; 

•.’here  72  is  anv  number  of  data  ohiects  that  can  be  USED  by  a 
PROCESS. 

A PROCESS  can  n"PTV'’  any  number  of  OUTPUTS,  S^ts,  ENTITIES, 
gpcps  and  El^^NTS.  An  optional  USING  clause  can  be  used  in 
conjunction  with  t^»  DERIVE  statement  in  the  following  manner: 

DERIVE?  PI  USING  E2; 


where  r?  is  any  number  of  data  objects  that  may  be  USED  by  a 
PROCESS . 


An  INPUT,  SET,  ENTITY,  GROUP  or  ET.  Ed  ENT  can  be  USED  by 
number  of  o?ncr  ■S='c.  An  optional  DERIVE  or  UPDATE  clause  may  be 
usea  in  conjunction  with  the  USFD  statement,  in  the  following 
raann  er : 


USED  BY  PI  TO  DERIVE  E2; 


Where  E2  is  a"v  number  of  data  objects  that  can  be  DERIVED  by  a 
PROCESS. 
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1 
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| RELATION 

1 

1 

1 

1 

1 

1 

1 

• 

USES  M3 

. USES  13 

• 

• 
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. USFS  U2 

• 

• 

P'PTVES 

U1 

. PE  FI VSS 

Ml 

• 

• 
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, UPDATES 

m 

. MAINTAINS 

♦ ♦ ♦ ♦ ♦•--- -♦ 

•'ll  II 

| rNPM'"  | j PPOCESS  | | OUTPUT  | 

I | US  TP  n 2 | | DEPIVES  U1  | | 
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UPDATES  Ml  . 
DFPTVES  nl  , 
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USES  T| 2 
DEPIVES  rj  1 
UPDATES  U1 


+ 

I I 

I ET.r"SNT  | 

I I 

♦ ♦ 

Mi,  0?  and  M3  ar-?  ootional 

using  EL?rE»r,  GROUP,  ENTITY  and  INPUT 
U2  *■  c deriv*  ELS  MENT  , GROUP,  ENTITY,  SET  and  OUTPUT 
M?  to  updaTp  EI-E  M7NT , GPOUP,  ENTITY  and  SET 


— ------  * 

I I 

| GPOMP  | 

I I 

«— * 


Pigure  2.4.3 

UP L STATEMFFT3  »OR  DATA  MANIPULATION 


I 
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Phiect 
Name  in 
St  a temen  t 
Sect  ion 

Tv Dfi  INPUT  OUTPUT  SET  ENTITY 


INPUT  TO  DERIVE3  TO  DFRIVE/UPCATE3  TO  DEP IVE/U PD ATE3 

OUTPUT  USING*  USING*  USING* 


SET 

ENTITY 


USING  5 

TO  DERIVE3  TC  DERIVE/UPDATE3  TO  DERIVE /U PD ATE3 
USING5  USING5 

USING5 

Tn  DERIVE5  USING5  USING5 

TO  DFRIVE/UPDATE3  TO  DERIVE  /npDATE3 


GROn  T5 


RL1?m  ENT 


USING5 

TO  CEPIVE3  USING5  USING5 

TO  DFPI VE/UPDATE3  TO  DERIVE /UPDATE3 

USING5 

”’0  DEFT V17  USING5  USING5 

"'0  DERI VE/UPDATE 3 TO  DERIVE /UPDATE3 


PPOCFNS 

U SING  7 

DERIVES  DEPIVES 

DERIVES 

mr.  DERIVE"  USES 

USES 

UPDATES 

UPDATES 

USING7 

USING  7 

TC  DERIVE/UPDA^E® 

TO  DERIVE /UPDATF" 

Q2I 

GPOUP 

ELEMENT 

/■> p Tj»r 

TO  PEPI VE/UPDATE3 
USING* 

TO  DEFI VE/UP DATE 
USING* 

CT'T' 

TO  DERI VE /UPDATE3 
USING5 

USING  5 

mr  DERIVE/UPDATE3 

TO  DERIV  E/U  PDAT  E3 
USING5 

USING5 

TO  DEPI VE/UPDATE3 

GROUP 

rL  ?U "NT 

USING5 

TO  DEP I V E /UP DATE3 
USING5 

TO  DPP  I VE/UPDATE3 

USING5 

"0  DERIVE /UPDATE3 
USING5 

TO  DERI VE/U  PD AT  E3 

r>pnr  »3c 

M A IN"' A INS 

derives 

USES 

UPDATES 

USING  7 

”C  DFRIVE/UPDATE" 

DF°  I VES 

USES 

UPDATES 

USING7 

TO  DFRIVE/UPDATE® 

follcvlnq  mao  for  footnotes) 

""able  ?.  a . i M°L  Statements  Related  *o  Derivation  Definition 
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PPOCrSS 

IMOrim 

u r ' r n y 

OT'T  PU~ 

ur  ptve  r 

BY 

c ^ 

USED  B Y 

nn!)A7r  n 

s V 

nE  riv7  r 

3Y 

',rTTY 

DERIVED 

3 Y 

M^DAT*? 

PY 

USED  BY 

b"LATTC»' 

K ATN'r  A T 

N^P  PY 

0 o 0 U P 

DE  RTV  E P 

PY 

UPU»  VVT 

3 Y 

U* SD  BY 

ELEV*N? 

^ERTV^E 

PY 

UPDATED 

3Y 

USEr  n Y 


PROCESS  '""I  LI  7.  FS 

U'TITEEP  BY 


Table  2.4.3 

UPL  Statements  Related  to  Derivation  Definition 

(Continued) 


?oot notes: 

3 Used  in  condunction  with  the  USFE  BY  stateaent. 

♦ Used  in  conjunction  with  the  TEPIVED  3Y  statement, 

mav  have  PEnE  MDI N G ON  and  ^OF  EACH  clauses. 

* Used  in  conjunction  with  DERIVED  BY  and  UPDATED  BY  stateaent, 

may  have  DEP^NPING  CN  and  EOP  EACH  clauses. 

7 used  in  coniunction  with  DERIVES  and  UPDATES  statement, 
mav  have  DEPENDING  ON  and  EOR  EACH  clauses. 

9 Used  in  con  junction  with  USES  statement. 
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USES 


ELF  WEST 

GROUP 

INPUT  OUTPUT 

ENTITY 

SET 

usp.s  y 

X 

X 

X 

X 

USES  TO  TEPTVZ  X 

X 

X 

X 

X 

USrS  To  UPDATE  X 

y 

X 

X 

X 

DERIVES 

np«»  ivEf/ f usr  vo>  >: 

f DEPENDING  ON} 

[ PDF  ^CU  1 

x 

X 

X 

X 

UPDATES 

UPP»  TFS/ (USING}  X 

{ DTP  E NPT  NG  ON} 
f "OP  EACH  } 

X 

X 

X 

X 

DEPIVES  or  UPDATES 

ELF  N ENT 

GROUP 

INPUT  OUTPUT 

ENTITY 

SET 

USES 

USES  TO  DERIVE  X 

X 

X 

X 

X 

USES  TO  UPDATE  X 

X 

X 

X 

t>pd  j-vFS  X 

X 

X 

X 

X 

DEPTVEc/fUSING)  X 

(DEPENDING  ON} 
f ”0?  EACH  } 

X 

X 

X 

X 

update*;  y 

X 

X 

X 

HPPA  TES/USTN 0 X 

X 

X 

X 

Table 
Data  Derivation 
uses,  updates  and 


2.4. 3.’ 

Relationships  for 
DPRIVBS  Statements 
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r y pMr  ajt 

GROUP 

INPUT 

p fc v T VT.C 

Mot  Allowed 

Vot  Allowed 

Every  INPUT 
should  be 
RECEIVED  by 
at  least  one 
P^OCFSS 

GFNF  FATE  c 

Vot  ? 1 low  <3  1 

Not  Allowed 

Not  Allowed 

uses 

F very  ELF  K PN'T’ 

At  leas*-  one 

At  least  one 

should  bo  used 

ELEMENT  in 

ELEMENT  in  the 

bv  at  least 

the  GROUP  is 

INPUT  is  used 

on e process 

used  bv  the 
PROCESS 

by  the  PROCESS 

ov  p r vrq 

Value  of  an 
urrpi,""  j.  s 

d e r v *d  b v 
the  PROP  ESS 

Value  of  at 
least  ore 

ELEMENT  in  the 
GFOUP  is  de- 
rived bv  the 
PROCESS 

Not  Allowed 

UopATFS 

1)  Value  of  ar 
TLrMI  NT  i «s 
updated  bv 
‘h»  PP^CEES 

2)  T’L',i-::«T 
should  be 

rr nt a inft 

in  a*-  least 
one  ^ VTI*’  Y 

1)  Value  of  at 
least  one 

EL EM  EM T in 
the  GROUP  is 
updated  by 
PROCESS 

2)  GROUP  should 
be  CC  NT AIM  ED 

in  at  least, 
one  F NT!TY 

Not  Allowed 

Table  2. 0.3.2 

rata  Derivation  (PRCCESS)  Semantics 
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OUTPUT  ENTITY 


cpCFTVFc  No*:  allowed  Not.  Allowed 


0pMr  FA^ES  Every  OUTPUT  Not  Allowed 
should  he 
r,  •."•cp  by 
ah  1 e ast  ora 

’’FOO^SE 


SET 


Not  Allowed 


Not  Allowed 


rszr 

Not  Allowed 

At  least  one 
ELEMENT  in 
the  FNTTTY 
is  used  by 
the  PROCESS 

At  least  one 
FLEMENT  in  the 
SET  is  used  by 
PROCESS 

D?’)  Type 

value  of  a*- 
leas*  one 
’LEEET"  in 

0 "TP” T is  de- 
rive 1 hv  the 
p r r)£ ? cc 

At  least  one 
ELEMENT  in 
the  FNTTTY 
is  derived 

At  least  one 
ELEMENT  in  the 
SET  is  derived 

' 

nr>n  \ TF5 

Not  Allowed 

Value  of  at 
least  one 
ELEMENT  in 
the  FNTITY 
is  updated 
by  the 

PPOfESS 

- , 

Value  of  at  least 
one  ELEMENT  in  the 

SET  is  updated  by 
th<*  PROCESS 

'"able  2. 4. 1.2 
(Continued) 

ij 

i 

t 


1 

« 

I 
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A S*T,  ENTITY , GROUP  or  ELEMENT  may  be  UPDATED  by  any  number  of 
PROCESSES.  An  optional  USING  clause  may  be  used  in  conjunction 
with  the  U^DA^ED  statement  in  the  following  manner: 

UPDATED  8Y  Pi  USING  E2; 

Where  E2  is  any  number  of  data  objects  that  may  be  USED  by  a 
PROCESS. 

mh»  optional  clause  DEPENDING  ON  may  be  used  in  conjunction  with 
the  urCA^ED  statement  in  the  following  manner: 

UPDATED  BY  PI  DEPENDING  ON  E3 

where  El  is  1 ist-of- elements  or  condition-names. 

The  optional  clause  ’’’OR  FACH  may  be  also  used  in  the  following 
mann  er: 


UPDATED  BY  Pi  FOR  EACH  E4 

Where  '4  is  list-of-entity,  input,  output,  group,  element, 
set- names. 

"he  three  optional  clauses  can  be  used  together: 

UPDATED  by  P1  USING  E2  DEPENDING  CN  E3  FOR  EACH  E4 

An  OUTPUT,  SET,  ENTITY,  GROUP  or  ELEMENT  may  be  DERIVED  by  any 
number  of  PROCESSES.  An  optional  USING  clause  may  be  used  in 
conjunction  with  the  DERIVED  statement  in  the  following  manner: 

DF»TVFD  BY  PI  USING  E2; 

Wher°  E2  is  any  number  of  data  objects  that  may  be  USED  by  a 

PROCESS. 

The  optional  clause  DEPENDING  ON  may  be  used  in  conjunction  with 
the  DERIVED  statement  in  the  following  manner: 

DFPIVED  BY  PI  DEPENDING  ON  E3 

where  ?!  is  1 isf.-of- c lement s or  condition-names. 

The  optional  clause  nor  FACH  may  be  also  used  in  the  following 
manner : 


DERIVED  BY  PI  FOR  EACH  E4 

Where  r4  is  list-of-entity,  input,  output,  group,  element, 
set- names. 


The  three  oDtional  clauses  can  be  used  together: 
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DERIVED  hy  pi  USING  E2  DEPENDING  ON  E 3 *OR  EACH  E4 

A RELATION  mav  be  MAI  N™AT NFD  by  any  number  o*  PROCESSES,  and  a 
process  mav  M * T n t A T . . any  number  of  RELATIONS . 

""he  optional  clauses  DPPE  NDI  NG  ON  and  FOR  EACH  can  be  used  in 
coni  unction  with  the  MAINTAINS  statement  in  the  following 
manner: 


”AT»r\INEO  BY  M DEPENDING  ON  E3  FOR  EACH  E4 
Where  PI,  ”1,  c'4  arc  the  same  as  above. 

A PF  OrFS  s mav  have  arv  number  of  PROCEDURE  comment  entries 
specified,  tu*  all  the  comment,  entries  will  be  combined  into  one 
PPP''  3D  up  T comment  entry  when  presented  in  any  URA  report. 

A SFT  or  RELATION  miv  have  any  number  of  DERIVATION  comment 
entries  specified,  but  all  these  comment  entries  will  be 
'■'ombin^d  into  one  nrFTVA7IPN  comment  entry  when  presented  in  any 
URA  renort. 

wh»n  a collection  of  data  (e.7.,  an  FNTTTY  or  GROUP)  is  USED, 
this  implies  tVat  at  least,  one  ELEMENT  within  the  collection 
(assuming  the  collection  is,  or  will  be,  broken  down  to  one 
CT. E v FN’7'  level)  is  USED. 

When  a collection  of  da*a  is  UPDATED,  this  implies  that  at  least 
on  * vt.vmpu'-  within  the  collection  is  UPDATED. 

When  a collection,  of  data  is  nfRi ved , this  implies  that  at  least 
one  ELEMENT  within,  the  collection  is  DERIVED. 

whenever  P"’R ciros  vs  or  processors  access  data,  whether  deriving, 
updating  or  usini  i *■  , the  CLASSIFICATION  of  the  data  and  the 
? ECU  r T1’1  Y - ACC  E~s-->  touts  of  PROCESS  or  PROCESSOR  should  match.  In 
order  to  mutch,  the  PROCESS  or  FFOCESSOR  should  have 
*"CrJ®T7Y- ACE  FEE-  r igh  TS  a*  a level  greater  than  or  equal  to  the 
CLASSIFICATION  of  the  data  oh-yec*-. 

3.4.4  Data  Derivation  Common  Equivalents  and  Usage 

Tn  most  manual  documentation  methods,  the  information  related  to 
••data  derivation"  is  usually  implicitly  included  in  flow  charts. 
Flow  charts  usuallv  contain  more  than  lust  the  "data 
derivation,"  ar,  1,  consequent  lv,  data  derivation  may  not  be 
clearly  presented. 

A PrEC1700  that  is  f1""TlIZFP  represents  some  function  within  the 
system  tha*  is  incorporated  by  two  or  more  higher  level 
DT5UCFE<7Fc.  For  example,  a validation  routine  might  be  1 urqcess 
ur,TT.T?r'D  bv  several  other  PPOCFSSFS  to  perform  their  defined 
function  s . 
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FFOC EDMR  E common*-  entry  within  the  PROCESS  description  may 
ho  used  to  describe  the  algorithms  required  to  define  th » 
PROCESS.  Sirce  the  PRCC5DUP ? is  text,  decision  tables  may  be 
inol uded . 

i 

’’’he  DERIVATION  comment  entry  within  the  SET  or  RELATION 
descriptions  may  ho  used  to  define  the  rules  to  derive  an 
occurrence  of  a RELATION  between  two  ENTITIES,  or  occurrences  of 
a member  within  <1  TP"". 


2.4. S Data  Derivation  Outputs 

The  PICTURE  report,  (with  the  PA  ""A  option  in  effect)  can  be  used 
to  nresen*-  daM  derivation  relationships  (USES,  UPDATES,  and 
P2P7VI3)  among  3 E^S,  IN  PUTS , OUTPUTS,  ENTITIES,  GROUPS,  ELEMENTS 
and  FPecFSS^S  in  a graphical  format. 

mhe  FX^FNP^d  PTC',,Pp  report  (with  the  DATA-FLOW  orMon  in 
effect)  can  be  used  to  present  the  all  da*a  derivation 
relationships  ("SEE,  UPDATED,  DERIVED,  G ENEF AT ED , and  RECEIVED) 
amona  SFTS,  INPr!'rc,  OUTPUTS,  ENTITIES,  GPCUPS,  ELEMENTS, 
PROCESSES,  and  T v'’"7’?  F ACES  in  a graphical  tree-struck  ured  format 
looirinn  FORWARD  or  BACKWARD  in  the  tree. 

"he  rror£sc- lNr»UT/DU'rPT"  report  presents  most  of  the  information 
as  described  above  for  PROCESS  names  only,  but  in  an  alternate 
forma*-.  “'"his  report  will  also  present  any  DESCRIPTION  and 
PPOCFD’J?”  common*-  entries  related  to  the  PROCESS  names. 

Th e EA"A  ppoc^SS  renor*  presents  the  interaction  of  data  objects 
with  CT,orESSE~  in  a matrix  format.  This  has  the  advantage  of 
presenting  the  dependencies  of  data  by  PROCESSES  for  the  entire 
system.  * second  matrix  is  also  produced  *■?  present  the  degree 
in  which  PROCESSES  interact  with  each  other;  i.e.,  to  produce 
data  that  other  PROCESSES  use  or  to  require  data  that  other 
pn'>cccSES  produce. 


2.4.f  Data  n r rival ion  Completeness  Check s 


0 

rvery  °ROCESG 
UPD  ATI  NO  . 

should 

acquire 

some 

data  either  by 

USING  or 

?) 

i 

Every  PROCESS 
PPD AmTNG. 

should 

produce 

data 

by  DERIVING  or 

by 

• • 3) 

pvory  SE”  should 

USED  or 

UPDATED  by  some  PROCESS . 

4)  Everv  F " T I T Y should  be  USED  or  UPDATED  by  some  PROCESS. 

b>  Every  T7T.FMEN'r  in  an  ENTTY  should  serve  at  least  one 

pur  pose : 

- I DEN'"  I ?I p R of  the  ENTITY 

- USED  hv  snio  PROCESS,  or 

- UPDATED  bv  some  PROCESS. 

6)  Processing  statements  in  which  GROUPS  appear  should  apply 
to  at  least  on®  ET,emfn’p  in  the  GROUP. 


F ACT  I USER  REQUIREMENTS  LANGUAGE  MANUAL 


UM  80/HTiLTrcS/URL  USER'S  MANUAL 


95 


■’)  fverv  ELEMENT  CONTAINED  in  an  INPUT  should  be  USED  in  some 

wav . ] 

S)  Fverv  ELEMENT  CONTAINED  in  an  ENTITY  should  serve  a 

purpose.  1 

9)  Ever V FIEMEN"'  CONTAINED  in  an  OUTPUT  should  be  DERIVED  by  4 

some  PROCESS.  I 

19)  An  ELHM.E  NT  CONT  ATNED  in  an  INPUT  should  not  be  DERIVED. 

11)  An  ELEMENT  should  only  be  DEFIVED  once.  1 

12)  Every  ELSMFN"  *»SED  by' a PROCESS  should  be  available  from 

some  source:  1 

i)  INPUT 

ii)  DEFIVED  by  some  other  PROCESS 

iii ) From  an  ENTITY.  j 


2."  Svstem  Size 

Th"  complete  specification  of  requirements  for  the  target  system 
requires  statement  of  parameters  that  specify  the  volume  of  work 
♦ha4-  the  svstem  will  have  to  do  and  the  amount  of  resources  that 
iv  will  require.  Two  ♦•ypes  of  data  should  be  given. 

^ize  - number  of  members  in  each  SET,  number  of  repetitions 
in  each  repeatin  GPOUP  in  an  INPUT,  etc. 

volume  - number  of  instances  of  INPUTS  and  OUTPUTS,  number  of 
■ fimps  PROCESSES  will  be  executed,  etc.  in  a given 
p eri od  of  hi  me  . 

In  URL,  the  na’-ame^-ers  which  characterize  size  are  called 
SYST'Fv-p  b?ak  rye;*  g;  they  can  be  name  symbolically  and  their 
values  expressed  numerically. 


* 

1 1 

! 

I 


k: 

i 

! 

i 


2.5.  1 System  Ul_7 e D b j ec t s 

SYS'T'Ey-PAPAt  - an  ob-ject  which  affects  the  size  of  the 

svsten.  It  is  given  a name  and  may  be 
given  a numeric  value. 

T N F F V A T - an  obieet  representing  some  time  period 

such  as  a week,  year,  millisecond, 
planning  period,  etc. 


2.5.2  System  size  Fc  > at  ionsh  i ps 
VALUES 

A «YSTEf-piP  may  have  a VALUE,  or  a ranae  of  VALUES.  An 

FT. ? M w N mav  also  have  a VALUE  or  range  of  VALUES  associated  with 
it. 
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CARDINALITY 

An  F *:-!•*■  Y,  or  SF",  or  P^tATION  may  have  a CARDINALITY. 

CONN  * CTT  VITY 

A R3TA"’T1V  >iav  h ave  a CONNECTIVITY  define!  by  specifying  two 
S Y ST  E M-  P A PA  M F T*’R  S . 


HAPPEN? 

» n 7 N PU'r , 0 n'“P,lT  , ?VFr,  or  PROCFSS  may  HAPPEN: 

system-parameter  TTHFE-PHR  interval 
I vr  P Y systen-na  r a me  ter  interval 
wt*"hin'  ry^t em-narameter  interval  AFTEP  event 
svs tern- na meter  interval  AFTER  event 


CON? If TT 

» 3*?  mav  -0NSI37  of  a SYSTEK-PA.  RAMET3P  (number)  of  FNTITIES, 
INPUTS,  or  OUTPUTS.  An  I NPTj - f OUTPUT,  ENTITY,  or  GROUP  may 
CONSIST  of  a SYSTRy-PAPAKFTEP  (number)  of  GROUPS  and/or 
EL  R**  ENT? . An  INT3FVA  I may  CONSIST  of  a S YSTHK-P  AF.AHETEE 
(nuraher)  of  INTERVALS . 


R.5.3  Sy  stem  "ize  Syntax  and  Reman  tics 

The  objects  and  relationships  involved  in  describing  system  size 
are  shown  oictorially  in  Fiqures  2.5.3,  2.5. 3,1  and  2.5. 3.2,  and 
in  tabular  ^ o rm  in  Table  2.5.3. 

Th»  VALUE  or  VRL'JR’S  associated  with  a SYST3M-PAF  A METER  or 
DLEMFNT  must  be  numeric  and  once  a VALUE  (or  VALUES)  has  been 
assigned,  m other  VALUES  may  be  given  to  it. 

CARDINALITY  specifies  a number  of  occurrences.  With  respect  to 
SETC,  it  specifies  tbe  number  of  ENTITIES,  INPUTS,  or  OUTPUTS 
tha*-  mav  he  CONTATNFD  in  the  SET  at  any  one  time.  With  respect 
*o  PNCITTF5,  it  specifies  the  number  of  occurrences  of  a 
particular  ENTITY  in  the  system  at  any  one  time.  With  respect 
to  RELATIONS,  i*  specifies  the  number  of  connections  made 
between  ENTITIES  via  a particular  DELATION.  A particular 
ENTITY,  S*"1,  or  PL  I A "TON  mav  have  only  one  CAPDTNALITY . 

COHNFC,rT VT'"Y  specifies  the  structure  and  magnitude  of  a 
RFLATTN.  A particular  WEI ATTON  may  have  only  one  CONNECTIVITY. 

"he  HAPPENS  statement  specifies  the  number  of  occurrences  of  an 
INPUT,  output,  FV*NT,  or  PROCESS  in  a given  time  interval. 
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Th»  CONSISTS  statement  used  in  conjunction  with  a SYSTEM- 
DAPAM1?TFP  specifies  that  for  each  occurrence  of  a given  SET, 

Q. q . , the  data  CONTAIN"!)  in  it  occurs  the  designated  number  of 
times.  Any  particular  data  object,  may  only  consist  of  another 
data  ohdect,  one  given  SYSTEE-P ARAMETEF  number  of  occurrences. 


0 . '5 . 4 System  S^ize  Tommon  Fgui valent  and  Usage 

Tn  t he  usual  ■not  hods  cf  system  documentation,  description  of 
Kiz°  and  volume  aspects  are  incorporated  into  the  descriptions 
of  other  objects  as  ruirerical  values. 

ene  important  feature  of  UPL  in  specifying  size  is  that  it 
permits,  and  in  fact  encourages,  all  such  specifications  t.o  be 
symbolic,  i.e.,  each  parameter  is  given  a name.  Consequently, 
all  situations  in  which  a given  parameter  appears  can  be 
collected  and  examined.  Numerical  values  need  only  be  assigned 
at  the  time  at  which  they  are  definitely  needed.  For  example, 
when  a system  is  initially  being  described,  it  may  only  be  known 
tha*  the  orouo  "job- data"  CONSISTS  of  the  element  "occupation." 
It  may  rot  be  known,  or  rot  specified  until  much  later  that 
job- data  CONSISTS  of  3 or  6 occurrences  of  "occupation." 
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Figura  2.5.3  Relation  of  Objects  to  a SYSTEM  PARAMETER 
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2.5.5  System  Size  On t puts 

To  obtain  information  specifically  about  one  or  more 
SYSTEM- PARAMETERS,  the  FORMATTED  PROBLEM  STATEMENT  may  be 
generated.  Since  very  few  of  the  statements  involving 
SYSTEM-P AFAM ETERS  have  complementary  statements,  much  of  the 
information  presented  in  the  FORMATTED  PROBLEM  STATEMENT  will  be 
ir.  comment  format. 


2.5,6  System  Size  Completeness  Checks 
’’’he  following  checks  can  he  made: 

1)  Fv®ry  IN0""  should  have  a HAPPENS/TIMES  statement. 

2)  Every  OUTPUT  should  have  a HAFPENS/TIMES  statement. 

1)  Every  SET  should  have  a CARDINALITY  statement. 

H)  Every  ENTITY  should  have  a CARDINALITY  statement. 

5)  Every  PROCESS  should  have  a HAPPENS/TIMES  statement. 

6)  Every  EVEN?  should  have  a HAPPENS/TIMES  statement. 

7)  Every  INTERVAL  should  be  used  in  some  statement. 

8)  Every  S YST3 M-PA F AMETEE  should  be  used  in  some  statement. 


2*5  Syst em- Dynam ics 

The  description  of  *he  contents  of  INPUTS,  OUTPUTS,  ENTITIES, 
GROUPS  and  structures  of  PROCESSES,  and  the  relationships  among 
these  ob-jects  produced  up  to  this  point,  gives  a "static" 
description  of  the  system.  This  does  not  in  itself  state  the 
requirements  for  the  dynamic  behavior  of  a system.  To  do  this, 
one  must  describe  those  inputs,  conditions  and  events  which  may 
influence  what  processing  is  performed,  or  the  order  in  which  it 
is  performed  . 


2.6.1  System  Dynamics  Objects 

CONDITION  - a statement  which  can  be  in  one  of  two  states, 

mP U E cr  FALSE  (YES  or  NO,  etc.)  . ?he  statement 
is  givQp  a unique  name. 

rVT NT  - an  object  used  ♦o  describe  a happening, 

“vterr.al  or  internal  to  the  system,  or  an 
occurrence  which  causes  something  else  in  the 
system  to  happen. 


* 


I 
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2.6.2  s»qw- Dyna nip s Relatj  onsjji  P$ 

CAUSES/C  A USED 

An  " VFNT  or  INPUT,  or  a CONDITION  BECOMING  TRUE  or  FALSE,  CAUSES 
an  ?:VSNT.  An  FVFNT  is  CAUSEO  by  an  EVENT,  an  IN  PUT,  or  a 
CONDITIO”  UPCOMING  T F UE  or  FALSE. 

TNCSPTIO V-CAHS^S/CV  INCEPTION 

INCFPTIOV  of  a PROCESS  CAUSES  an  F VENT , or  an  EVENT  occurs  ON 
INCEPTION  of  a PRCCFSS. 


I NTP  F F UP^S  /I  'C’Tn  *5  UPTFD 

A PROCESS,  EVENT  or  INPUT , or  a CONDITION  BECOMING  TRUE  or 
FALSE,  INTrpprjpTS  9 PROCESS.  A PROCESS  is  INTERRUPTED  by  a 
PROCESS,  EVENT  or  INPUT,  or  by  a CONDITION  BECOMING  TRUE  or 
PALS*. 


MAKES/M  A DE 


An  ? VrNT , INPUT  or  PROCESS  MAKES  a CONDITION  TRUE  or  FALSE.  A 
CONDITION  is  MADE  IPUF  or  FALSE  hy  an  EVENT,  INPUT  or  PROCESS. 


TERM  TNA  TES/TE  ?.MJ  NAT”D 

A PROCESS,  EVENT  or  INDO",  or  a CONDITION  BECOMING  TRUE  or 
FALSE,  TERMINATES  a PROCESS.  A PROCESS  is  TERMINATED  by  a 
PROCESS,  EVENT  or  INPUT,  or  by  a CONDITION  BECOMING  TRUE  or 
FALSE. 


'"ERM  TNATION» C AUS ES/0 N TERMINATION 

TERMINATION  of  a PFOCESS  CAUSES  an  EVENT,  or  an  EVENT  occurs  ON 
TERMINATION  of  a PROCESS. 


"■RIGGPRS/TRIGGERED 

A PROCESS,  EVErT  or  INPUT,  or  a CONDITION  is  BECOMING  TRUE  or 
*ALSE,  TRIGGEPS  a PROCESS.  A PROCESS  is  TRIGGERED  by  a PROCESS, 
EVENT  or  INPUT,  or  by  a CONDITION'S  BECOMING  TRUE  or  PALSE. 

Conditional  actions  for  each  of  the  above  relationships  can  be 
described  by  the  use  of  the  DEPENDING  ON  clause.  Also, 
repetition  of  conditional  actions  can  be  described  by  the  use  of 
the  FOP  EACH  clause. 
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WHILE 

A CONDITION  may  he  TRUE  WHILE  or  FALSE  WHILE  some  criteria  hold. 


2.6.3  System  Dynamic s Syn ta x and  Semantics 

The  ohlects  and  relationships  involved  in  describing  system 
dynamics  are  shown  pictorially  in  Fiqure  2.6.3  and  in  tabular 
form  in  Tahle  2.6.3. 

INCH  PTTPN  or  TER  MINA  ^ ION  Qf  a PROCESS  may  CAUSE  any  number  of 
EVENTS.  Similarly,  an  EVENT  may  occur  ON  INCEPTION  or  ON 
TERMINATION  of  any  number  of  PROCESSES.  The  INCEPTION  of  a 
PROCESS  is  its  beginning,  TERMINATION  is  the  completion  of  the 
PROCESS. 

An v number  of  EVENTS,  INPUTS,  and/or  CONDITIONS  may  CAUSE  and 
EVENT.  However,  a separate  statement  is  reguired  for  each 
CONDITION  involved.  Similarly,  any  number  of  EVENTS  may  be 
CAUSED  by  a given  collection  of  EVENTS,  INPUTS,  and/or 
CONDITIONS. 

Any  number  of  EVENTS,  INPUTS  and/or  PROCESSES  may  MAKE  a 
CONDITION  '''PUS  or  FALSE.  Anv  number  of  CONDITIONS  may  be  MADE 
TRUE  or  FALS E bv  a given  collection  of  EVENTS,  INPUTS  and/or 
PPOC^SSFS.  Only  ore  of  the  values,  TRUE  and  FALSE,  may  be  used 
in  a qiven  MAKES  of  * ALE  statement.  The  term  MAKES  implies 
setting  the  value  or  a CONDITION. 

Any  number  of  PROCESSES,  EVENTS,  INPUTS  and/or  CONDITIONS  may 
"'RISC*!.,  INTP-'FU^  or  TERMINATE  a given  PFOCESS.  Any  number  of 
PROCESSES  may  be  •'’R T OGEE  E P,  INTSRP  DPTED  or  TERMINATED  by  a given 
collection  of  PROCESSES,  EVENTS,  INPUTS  and/or  CONDITIONS.  To 
a epoc^SF  is  to  initiate  it.  A PPOCESS  is  INTERRUPTED 
if  it  is  eligible  to  be  resumed  later,  while  it  is  TERMINATED  if 
it  i s ended  (whether  complete  of  not)  and  is  not  to  be  resumed. 

* CO NDIT ION  mav  onlv  have  one  WHILE  statement,  which  is 
exnressed  as  a comment  entry.  Should  more  than  one  be  specified 
for  a given  CONDTTTOw,  the  comment  entries  will  be  combined  (the 
second  added  to  the  end  of  the  first  and  so  on). 
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n F 0CP  S S EVENT 


PROC  ESS 

P P TGG  SF? 1 

tt3«t  mate  S » 

1 NT^F  eilP'p  S l 

TRIGGER'D  BY* 
TE^MINATU  BY* 

T.  N^ER  E D BY* 

INCEPTION-CAUSES* 

TEPMI NATION-CAUSES* 

TPIGGEFFD  BY* 

TERMINATED  BY* 
INTERRUPTED  BY* 

EVENT 

TF TGGEPS  * 

T E I N A'r  E S * 

T »JT^P  5 fJOT  S 1 

CN  INCEPTION  OF* 

ON  "’EPMT MARION  OP* 

CAUSES* 

CAUSED  3Y * 

CONDITION 

B ECO P TNG  (TnME) 

TPTGGEPS  (FALSE)* 

BECOMING  (TRUE) 

CAUSES  (FALSE)* 

BECOMING  (TRUE) 

'•’Privates  (false)* 

BECOMING  ("PUE) 

INmErRUPTS  (FALSE)* 
f*PU  F) 

M A DR  (PALSE)  BY* 

n’RnE) 

MADE  (FALSE)  BY* 

TNPUT 

TRIGGERS* 

TERMINATES* 

IN?PP HURTS » 

CAUSES* 

Table  2.6.3 

UP L Statements  for  Describing  System-Dyana ics 

» Conditional  (DEPENDING  ON)  and 
clauses  are  allowed. 

repetition  (FOR  EACH 
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CONDITION 

INPUT 

PROCESS 

{TRUE J 

MAK^S  — {FALSE}* 

T P IGGFRED  WHEN 

{TRUE } 

— BECOMES  {FALSE}* 

TRIGGERED  BY* 

TERMINATED  BY* 
INTERRUPTED  BY* 

tfpminated  when 

{TRUE} 

— BECOMES  {FALSE}* 

I N?CP  PUn?  F D WHEN 

(TRUE) 

--BECOMES  {FALSE}* 

EVENT 

{TRUE} 

PANES  --  {FALSE}* 

C A U^  E U FUEN  — 

TRU*} 

BPCOvEc  {FALSE}  » 

CAUSED  BY* 

CONDITION 

WHILE * 

{TRUE} 

MADF  {FALSE}  BY* 

INPUT 

{TRUE} 

MAK*S  — {FALSF1  * 

* Conditional  (pep^n ping  ON)  and  repetition  (fop  EACH 
clauses  are  illow»d. 

* coDP»en  + en^ry  onlv 


Table  2.6.3  (Continued) 
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^ . 8 . U System  nynamics  Common  Equivalents  and  Usage 

As  is  the  cas«>  w ith  system  size,  description  of  system  dynamics 
asn»cts  are  often  not  state!  explicitly  but  are  incorporated 
into  the  descriptions  of  other  oh-fects.  In  some  cases,  this 
typ«  of  information  is  nresented  bv  decision  tables  or  by 
decision  blocks  in  flow  chartinq  methods. 

Since  decision  tables  present  a plan  of  "action"  based  on 
conditions  an*  events,  they  may  be  qiv^n  in  the  PROCEDURE 
statement  for  the  appropriate  PROCESS,  if  desired. 

* list  of  SVE”7S  mcT GG^PING  a FPOCFSS  implies  that  each  one  of 
the  EVENTS  1'nxGOEpf”  the  PTOSES.  Since  an  EVENT  occurs  at  an 
instant  in  tin*1,  the  user  should  not  need  to  say  that  a 
combination  of  EVENTS  TRIGGERS  a PROCESS,  since  this  would 
require  that  all  the  EVENTS  occur  simultaneously. 

?v°r  though  there  is  no  wav  to  state  exnlicitly  that  a 
combination  of  CONDITIONS  tfiggeps  a PPOCFSS  , this  may  easily  be 
handled  bv  deFining  a new  CONDITION  to  represent  the 
combination..  ’’or  evamnle,  if  PROCESS  pi  is  TRIGGERED  when 
CONDITION  Cl  is  TPM E and  CONDITION  C2  is  FALSE,  the  user  may 
write: 

CONDITION  Cl; 

T PP Tr  WHILE; 

C ^ AND  NOT  C 2 ; 

nnoCFES  Pi  ; 

TFIGGF? ED  VHrN  C3  HECOy ps  TRUE; 

Anv  EVFNT  or  CONDITION  that  affects  the  system's  operation, 
should  be  defined. 


P.o. S System  rvn  amic  s Outputs 

tha  FORE  AT^E r nocPLEM  STATE*  ENT  may  be  generated  to  obtain 
information  about  one  or  more  CONDITIONS  or  EVENTS. 

Th » PForyss  CHAT  N rerort  will  show  structures  of  EVENTS  and 
PN0CSSSFS  con  nec  ted  by  TRIGGERS  and  'TRIGGERED  BY  statements. 


2.0.0  System  Pyp a mis s Completeness  Check  s 

1)  Every  T?VE')1'  should  be  associated  with  at  least  one 
CONDITION  or  PROCESS. 

2)  Every  CONDITION  should  he  associated  with  at  least  one 
EVENT  or  t>noCESS  . 

1)  Every  CONDITION  should  have  a TRUE  WHILE  or  a FALSE  WHILE 
statement. 
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Syst  em  A r chi  tort  t^ce 


The  system  architecture  description  deals  with  the  physical 
aspects  of  an  information  processing  system. 


2.7.1  Sy  stem  Architecture  Objects 


PROCESSOR  - 


an  otvject  that  can  "oerform"  a PROCESS. 


PESO  TJFCE 


U?JIT  - 


something  that  the  physical  elements  in  the 
target  system  consume  in  order  to  carry  out 
information  processing  functions. 

an  obiect  used  to  measure  RESOURCES. 


RESOURCE-USAGE-  used  to  define  a measure  of  the  RESOURCE 
PAR  A MFTFP  - usage  for  a PROCESS . 


?. i , 2 System  Architecture  Relationships 


COUSUtlES/COVET^p  RY  - 


PERFORMS /PERFORM  ED  RY  - 


MEASURFS/MFA  SUR7  0 IN  - 


A RESOURCE  may  be  CONSUMED  BY  a 
PROCESSOR,  and  a PROCESSOR  May 
CONSUME  an  amount  of  RESOURCE  PEP 
RESOUBCE-US  AGE-PARAMETER. 

A PROCESSOR  may  PERFORM  a PROCESS, 
and  a PROCESS  may  be  PERFORMED  BY  a 
PROCESSOR. 

A UNIT  may  MEASURE  a RESOURCE,  and 
a RESOURCE  may  be  MEASURED  IN  a 
UNIT. 


RESOUFCE-US AGE/R  ESDU BCE-  A PROCESS  may  have  a RESOURCE- 

USAG E-PARAMETER- VALUE  - USAGE-PARAMETER-VALUE  associated 

with  a RESOURCE-USAGE-PARAHETER . 


2.7.1  System  Arc hitect.gr e Syntax  a nd  Semantics 

"he  objects  and  relationships  involved  in  describing  system 
architecture  are  shown  in  Table  2.7.1. 

A PROCESS  may  have  an  arbitrary  number  of  RESOURCE-USAGE- 
PA  ° A MFTF  P and  PESPU  R CS-nS  AG  E-PA  RAKFTEE- VALUE  pairs.  (But  there 
can  cnly  be  at  most  one  such  pair  for  a particular 
PWSP UBCF-USAGE-P ARAM ETEP , ) This  pair  is  used  to  describe  the 
expected  resource  consumption  by  the  execution  of  the  PROCESS  in 
a PROCESSOR  independent  manner.  The  CONSUMES  statement  in  the 
PROCESSOR  section  specifies  the  name  and  amount  of  RESOURCES 
♦hat  are  consumed  p*r  RESOURCE-US AGE-PAR AMET ER  of  the  PROCESS  it 
performs.  This  measure  is  translated  to  a resource  consumption 
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value  by  nmlt.inl  vinrj  the  RESOURCE- USAGE- PAR A METE R- VA LUE  with  the 
r«3oucre-consuirntior-»alue  for  the  PESO U PCS- US AGE-PAR A ME  TER  in 
tba  CONSUMES  statement  of  the  PPOCESSOP.  For  example,  suppose 
that  there  is  a PROCESS  "Pi,"  and  a PROCESSOR  "PP1,"  and  that 
♦•he  RFSOUPCE  in  question  is  "C PU-TIME"  (measured  in  UNIT  of 
"rrcsc-SSCONPS")  , as  in  Figure  2.7,3. 


PROCESSOR  RESOnpCE 

UNIT 

FESCURCE- 

USAGS- 

PARAME2IE 

PROCESS 

PRnC  ESSO  P 

SUPPA  RTS  CON  SUERS 
PAP""  OF 

CONSUMES 

PER 

PERFOF  MS 

PFsonpcp 

CONc,TMEr 

ny 

ME ASUREC 
IN 

UNI'" 

vpA  SURFS 

RF  SO UWCF 

US  \C  V 
PARAMETER 

FESOUPCE- 
USAGE- 
PARAMETER- 
VALUE  FOR 

PFOCESc 

P E°FO  RMFD 

RESOURCE- 

USAGE 


"''able  2.7.3 

System  Architecture  Relationships 


PROOFS  S Pi  ; 

pm  SOURCE- US  AGE; 

ICO 

P 75  OCRS  S P?  ; 

PESOURCF-US  1 GE: 

2 00 

PPOCESSOP  PR1; 

PER  PORI1!  S Pi  ; 
consumes  c°n-rTFE  a' 
S T AT17  K5"!  TG; 


rx  a nple 
PPOCF  SSO? 


FOR  N 0— OF—  STATEMENT; 

FOP  MC-CF— STATEMENT 

RATE  CF  20  PEP  NO-OF- 

Figure  2.7.3 

of  tipl  statements  for 

nd  its  FESOURCE-usaqe, 


Here  "WO-OF-S1'1'’'  2MSNT" 
PROCESS  called  M has  a 
possible  interpretation 


s a p ESCHPCE-USA  GE-P  AR  ANETER . The 
value  of  100  for  this  parameter.  One 
of  this  statement  is  that  the  relative 
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difficulty  or  crnnlexity  of  the  PROCESS  is  such  that  it  would 
take  ino  a foments " on  a hypothetical  processor.  Other 
PPOC  SFces  mav  be  given  values  for  the  same  FESOtJ  FCE-OS AG  E- 
PACA  "F^FF.  For  example,  PROCESS  P2,  which  is  considered  twice 
as  difficult  or  complex,  is  given  the  value  200  for  this 
F '“'S  O M FC  p - HS  A G E-  ° ’ r i ^ f t p , Note  that  the  PESO  URGE- US  AGE- 
PA  ” A MFTF  R and  its  value  are  meant  to  be  PROCESSOR  independent. 
mhev  are  used  to  record  estimation  of  RF SOURCE-TJS AGE  independent, 
of  what  PPOCESSO*  performs  the  particular  PROCESS. 

In  the  rporPSPOP  section,  the  CONSUMES  statement  is  used  to 
r3cord  the  resource- consumpt ion-value  for  a RESOURCE- USAGE- 
PA^AMFITF.  In  the  examole  of  Figure  2.7.3,  20  is  the 
reso urce-con sumnt ion- value  of  the  PROCESSOR  "PR1"  for  the 
»FSO  UPCF-US  AGE-P  ARAM  FTFP  "NO-OF-ST  AT  EMEN  T.  " "MICRO-  SECONDS”  is 
the  name  of  the  UNIT  that  is  used  to  measure  the  RESOURCE  called 
MCnTJ-7  T*  **• 11 

This  statement  may  be  interpreted  as  saying  that  the  PROCESSOR 
»opt  •'  will  consume  ?0  microseconds  of  CPU  tine  per  "number  of 
statements"  (given  in  the  ppoCESS  description)  whenever  it 
oerforms  a PROCESS.  In  this  example,  2,000  (100  x 2C) 
microseconds  op  CPU  time  is  consumed  by  PROCESSOR  "ppi"  whenever 
it  performs  P^c^t  "pi,"  and  4,000  (200  x 20)  microseconds  for 
"P? . " 

Tt  is  possible  to  associate  more  than  one  RESOTJPCE-US  AGE- 
PAPA  i?TE  R (an  1 its  value)  for  a PROCESS.  It  may  be  used  to 
allow  for  th°  nossibilify  of  employing  two  completely  different 
tyo* ? of  Droc3ssors  (like  a computer  and  a person)  to  perform 
the  PROCESS.  Tn  this  way,  the  decision  as  to  what  PROCESSOR  to 
use  for  a particular  PFOr^ss  may  be  delayed  as  necessary  and 
changing  the  PROCESSOR  *or  a PPOCFSS  once  it  is  decided  is 
easier.  Having  more  than  one  pair  of  RESOURCE-US AGE-PAR AMSTERs 
ant  its  value*  may  also  be  used  to  describe  resource  consumption 
independently  for  more  than  one  resource.  Only  the  resource 
consumotion  value,  which  has  the  same  RESOURCE-USAGE-PAR ANETER 
in  both  nR0CFSS  and  PFOCFSSOR  sections,  is  taken  as  contributing 
to  the  actual  resource  consumption.  If  there  are  multiple 
instances  of  such  PAFAMETFRs,  the  net  consumption  for  a resource 
is  the  sum  of  all  the  consumption  values. 

Tha  nEPFORvs/P,rt!  "CRH 11 D PY  statement  is  to  record  the 
relationship  between  a PFTCESS  and  the  PROCESSOR  that  performs 
(i.3.,  carries  out,  does,  etc.)  the  PPOCESS.  A PROCESSOR  can 
nerfcrm  more  than  one  PROCFSSas,  but  a PFOCESS  can  be  performed 
by  only  one  PPocesfop, 

The  Ef ASMRES/wfa T'J  statement  is  to  define  relationships 
between  a (I MI-"  a n*  a RESOURCE.  A UNIT  may  measure  tore  than  one 
RFSOTJRC*’ , but  a ?re7nRCF  can  be  measured  only  in  one  UNIT.  The 
UNIT  name  that  appears  after  the  resource-consumption-value  in 
the  CCUSO?*S  statement  of  the  PROCESSOR  section  is  optional,  but 
if  it  is  given  it  must  be  the  correct  UNIT  name  for  that 
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PESOnFC* . 


2.7.4  System  Architecture  Completeness  Checks 

'’’he  completeness  checks  that  can  he  made  for  SAF  objects  are: 

1)  Every  PROCESS  should  he  PERFORMED  BY  a PROCESSOR  and  every 
FROCFSSOR  should  PERFORM  at  least  one  PROCESS.  At  each 
subdivision  of  PROCFSS  and  PPOCESSOP  SUBPARTS/PART  OF 
structure,  the  PERPOEMS/PERFOPMED  BY  relationships  of  the 
suhparts  should  be  consistent  with  the  relationships  of  the 
parent  objects. 

2)  If  a PROOFS  SOF  PERFORMS  * PROCESS,  at  least  one  common 
FFSOURCF-US  AGE-PAFANFTSR  must  be  defined  for  the  PROCESSOR 
(via  CONSUMES  statement.),  and  for  the  PROCESS  (via 
FESOURCS-Uc »GF  statement). 

3)  If  a SYSTEM-PARAMETER  is  used  for 

RF SOURCE -HS  AGE- P AP AKETER- VALUE  or  in  the  CONSUMES  statement 
cf  the  PROCESSOR  section,  it  must  have  a single  numerical 
value. 

4)  Every  UNIT  should  MEASURE  at  least  one  RESOURCE,  and  every 
PSSOUFCE  should  fee  measured  in  a UNIT,  and  CONSUMED  BY  at 
least  one  PROCESSOR. 


2 . * Properties 


The  facilities  lescrihed  in  this  section  are  available  to  aid 
all  aspects  documentation,  communication  and  analysis.  These 
facilities  also  provide  open-ended  classification  systems  since 
these  "qualifiers"  may  be  added  at  any  time  and  used  for 
retrieval  of  Darts  of  the  problem  statement.  They  can  be  used 
to  describe  any  of  the  ohjects  whether  in  the  organization,  the 
target  system  or  in  the  project.  They  may  be  used  in  cases 
where  the  analyst  wishes  to  include  some  information  in  the 
docu me^t atio n where  no  formal  syntax  is  available. 


2.B.1  Proper  t ie.s  objects 


«?yncnym 


KEYWORD 


M’S'IO  - 


is  used  t0  define  an  alternative  name  (alias) 
for  a gi ven  named  object  in  the  URL  description 
of  the  system. 

an  object  associated  to  one  or  more  names  for 
thn  purpose  of  selection  and  analysis. 

an  object  which  represents  text  relevant  to  one 
or  mor«  other  objects. 
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a ■’>"’9  inuTE  and  AT  TF 13 UTE- VALUE  - objects  used  to  describe 

cha  racteristics  of  objects  not  otherwise 
allowed  in  the  language. 

SOURCE  - ar.  object  which  is  to  be  referenced  for  more 

information  about  an  ob-ject.  Examples  of 
SOURCES  are  interview-reports,  company 
procedure  manuals,  documents,  etc. 

SECURITY  - an  obi^ct  which  identifies  what  points  of  the 

Dro  blent  statement  may  be  reviewed  by  what 
ind i viduals . 


■"RAC  E-Kr  Y - 


an  obi^ct.  which  is  used  to  correlate  objects 
which  exist,  in  different  data  bases. 


"•3.2  rr op^r  t_ Relationships 
UE5C  PTPr"rOM 

Anv  cMect  definei  in  the  problem  statement  may  have  a 
PFSC °TP'” TO*’ , which  consists  of  one  or  more  lines  of  narrative 
text,  n nn«?cc 7° ""Ton  is  not  a tlFL  object  and  does  not  have  a UPl 
name . 


P Y^c  K YY 

Ary  tvoe  Of  object  may  have  S YN ONYKS  and  a SYNONYM  may  be 
UESIG'JATFD  for  a given  object. 


ASS'”" 

Any  ohject  which  has  a relationship  with  another  object  may  have 
an  ASpvpp  st  a 1 05  ent . An  ASSERT  statement  asserts  that  one 
ohject  must  have  a particular  ATTRIBUTE  and  ATTRIBUTE-VALUE  when 
related  to  another  object. 


ATTRIBUTES 

Any  obiect  may  h av=-  ATTRIBUTES  with  corresponding 
ATmT  IBUTF-VA  LUFS  . 


xrYworns/APni.i"c 

Any  object  may  hav°  KFYWOPDS  associated  with  it  and  a KEYWORD 
mav  ATPT  Y to  any  t?r>e  of  object. 

SEE-MVMO/APPLr'S 
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Anv  obiect  nay  have  a SEE-MENf)  and  a MEMO  may  APPLY  to  any 
ohi“C*-t 


t 

i 


i 

i- 


eryjs  r"/A  PPL  I r 9 

‘nv  obiect  mav  have  a SOURCE,  and  a SOURCE  may  APPLY  to  any 

obiect . 

3ECT’  FIT  Y /AP^I. Trc 

Anv  obiect  nay  have  a SECURITY,  and  a SECURITY  may  APPLY  to  any 
o b 1 e c t . 


■"PACE-K'pY/APPLTc'  3 

Any  obiect  nay  have  a "PACE- KEY,  and  a TRACE- KEY  nay  APPLY  to 
any  cbiect. 


2.R.  1 Proper  t Tvntax  and  Semantics 

""he  cMec^s  and  relationships  involved  in  describing  properties 
are  shovn  oictoriallv  in  figure  2.8.3  and  in  tabular  form  in 
""able  2. P.l. 

A aiven  obiect  may  have  only  one  DESCRIPTION.  If  more  than  one 
DESCRIPTION  is  soecifiei,  they  will  be  combined  (concatenated  to 
the  end  of  ‘ha  previously  specified  DESCRIPTION).  when  entering 
e oe sc*t PTTO N into  the  data  base  it  is  important  to  note  that 
the  text  must  start  on  tf,e  line  following  the  word  DESCRIPTION. 

A given  obiect  may  have  any  number  of  SYNONYMS,  but  a given 
SYNONYM  mav  belong  to  only  one  obiect.  SYNONYMS  may  be  used 
anywhere  in  a °roblem  Statement  that  the  basic  name  may  be  used. 
* "YNCMYK  must  be  a URL  name. 

A given  obiect  may  have  any  number  of  KEYWORDS  associated  with 
it.  KEYWORDS,  however,  may  not  have  KEYWORDS.  A KEYWORD  may 
»?PLY  to  anv  number  of  obiect  names. 

A given  obiect  may  have  any  number  of  ATTRIBUTES,  but  for  a 
given  ATTRIBUTE,  may  only  have  one  ATTPI BUTE- VALUE.  ATTRIBUTES 
may  not  have  ATTRIBUTES.  An  ATTRIBUTE  can  have  any  number  of 
vain  es. 
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A qiven  object  nay  have  any  number  of  ASSEPT  statements  which 
relate  that  obiec*  to  other  objects  havinq  particular  ATTRIBUTES 
and  ATTPTBn'T'E-VA  LUES  . 

A given  object  may  have  any  numher  of  SEE-MEMO  statements.  A 
*EMO,  however,  may  not  have  any  SFE-MEMO  statements.  A MEMO  may 
AP°L Y to  any  number  of  named  objects. 

An  object  may  have  anv  number  of  SOURCES  and  any  SOURCE  may 
A P°L  Y to  any  number  of  objects. 

An  object  may  have  any  number  of  SECURITIES  and  any  SECUEITT  may 
APPLY  to  anv  number  of  objects. 

An  object  mav  have  any  number  of  TRACE-KEYS  and  any  TRACE-KEY 
may  APPLY  to  any  number  of  objects. 
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A r.  v y ne 
of 


Object  * 

KEYWORD 

MEMO 

ATTRIBUTE 

in / Type 
of 

Ohiect  * 

KEYWORD 

IS 

SEE- MEMO 

ATTRIBUTE 

IS 

KFYVOFD 

APPLES  TO 

SEE-MEMO 

ATTPIBUr F 

IS 

Mww0 

A P^LT  EE  "0 

KEYWORD 

IS 

ATTRIBUTE 

IS 

A^TF IPUTE 

KEYWORD 

T C 

SEE- NEMO 

A "TP  tPUTE 

V ALU  w 

KEYWORD 

IS 

SEE- MEMO 

SOU  PCS 

? P°LTES  ro 

KEYWORD 

IS 

SEE-MEMO 

ATTRIBUTE 

IS 

security 

A DUTIES  T0 

KEYWORD 

IS 

SEE- MEMO 

ATTRIBUTE 

IS 

TRACE-KEY 

APPLIES  T0 

KEYWORD 

IS 

SEE-MEMO 

ATTRIBUTE 

IS 

A Tr'RTBTr'E- 


value 

SOURCE 

SECURITY 

TRACE-  KEY 

IS 

Any  Type 
of 

Object 

Am~  P^BUTE 

IS 

SOURCE 

IS 

SECURITY 

IS 

TRACE-  KEY 

IS 

KEYWORD 

ATTRIBUTE 

IS 

SOURCE 

IS 

SECURITY 

IS 

TRACE-KEY 

IS 

"'HO 

ATTRIBUTE 

IS 

SOURCE 

IS 

SECURITY 

IS 

TRACE- KEY 

IS 

A ETP I3HTE 

SOURCE 

IS 

SECURITY 

IS 

TRACE-KEY 

IS 

A^TR IPUTE 
VALUE 

SOURCE 

IS 

SECURITY 

IS 

TRACE- KEY 

IS 

SOURCE 

ATTRT  BUTE 

IS 

SECURITY 

IS 

TRACE-  KEY 

IS 

SECURITY 

A^TRI BUTE 

IS 

SOURCE 

IS 

TRACE-  KEY 

IS 

^ R AC  E-KTY 

ATTRIBUTE 

IS 

SOURCE 

IS 

SECURITY 

IS 

* Other  than  KFYWO«P,  MEMO,  ATTRIBUTE,  ATTRIBUTE- VALUE , SOURCE 
or  S T CUP  ITT 

Table  2.8.3 

URL  Statenents  for  Describing  Properties 


r>AF'r 
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T.3.4  Prop°rt  i°g  £25125  £25  i v *l.°nt  s an  I Usage 

The  DESCRIPTION’  associated  with  a given  object  is  analogous  to 
any  tex*  description  presented  in  most  documentation  methods. 

It  may  contain  any  tables,  charts  or  figures  which  can  be 
displayed  hv  '■ho  output  device. 

A u?I  ?vNONY M has  the  same  meaning  as  commonly  used.  Its  two 
manor  uses  in  UP L are: 

1)  'n  redu<~^  the  number  of  characters  used  in  specifying  the 

Droblem  statement,  This  can  be  accomplished  by  assiqninq  a 
yerv  short  SYNONYM  to  each  user  defined  name  as  it  is 
def  inM  . 

?)  To  allow  different  problem  definers  to  reference  the  same 
object  by  different  names. 

KE vyopps  mav  bo  used  to  logically  group  several  objects  for 
retrieval  and  analysis  purposes.  For  example,  to  generate  UFA 
reports  for  only  'hone  PROCESSES  which  were  to  run  in  batch 
mode,  each  of  the  ccESSFS  could  have  the  following  KEYWORD 
st  at  «men  t : 

KEYW  ORD  : BATCH  ; 

Using  the  = facility  in  the  NAME-GEN  command,  all  the 
""DCFFE'S  with  a KEYWORD  'PATCH'  could  be  retrieved.  Any 
desired  oiPpu's  ccul*  bQ  produced  by  U^A  at  this  point. 

n-?"n  Tp-|"^r;  m ^ \ j;0  v,  e thought  of  as  qualifiers.  For  example, 

•■o  present  mo’s  and  length  information  about  an  ELEMENT,  the 
following  ATTRIBUTES  statement  might  be  used: 

A:»-DTp,r7c;;  ’•DDF  NUMERIC, 

LENGTH  o ; 

”h a ATTF IHUTE  statement  can  be  used  to  fill  any  number  of 
requirements  for  specifving  characteristics  of  objects.  For 
RFOCESSFS,  processing  nolo,  duration  might  be  given;  for  INPUTS 
and  OUTPUTS,  format  or  si7e  might  be  given;  etc. 

■"he  ASSERT  statement  may  used  to  present,  more  information 
about  ar.  existing  relationship.  For  example,  if: 

PROCESS:  ort-names  DERIVES  name  USING  number; 

an  appropriate  ASSERT  relationship  would  be; 

ASSFR'n  rame  tvne  char,  number  type  integer; 

U?L  provides  ‘H°  facility  in  KEYWORD  and  ATTETBUTF  statements 
for  the  classification  of  objects  by  a criteria  which  can  be 
defined  and  expanded  as  the  project  progresses.  The  additional 
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information  ran  be  added  at  any  time  daring  the  project  without 
list  urbi  ng  thj  data  gathered  up  to  that  point. 

SECURITY  and  sou?cp  refer  to  the  definition  of  the  objects,  not 
to  the  security  of  data  or  source  of  data  in  the  target  system. 

"*he  TFACE-KPY  statement  is  used  to  correlate  objects  contained 
in  different  lata  bases.  The  security  level  in  a logical  system 
design  data  base  and  a security  level  number  in  a physical 
system  desinn  ^ata  base  may  both  have  the  statement: 

7RACF-KEY:  securitv-le  vel-key; 


P.  8.  s Properties  r»u t puts 

The  DICTIONARY  report  presents  SYNONYMS,  the  DpSCPPITION  and 
vr,YWOROE  for  each  name  given  as  input. 

Th<>  NAMF-gSN  command  can  retrieve  all  nam^s  with  a particular 
KEYWORD  value  by  usi no  the  KEY  rarameter.  Reports  may  then  be 
oenerat»d  *or  tka  selected  names  by  utilizing  the  default 
facilities  of  UP  \ . 

The  a-tc -nM"  f report  presents  information  about  ATTRIBUTES  in 
‘ho  problem  statement  by  presenting  those  objects  the  particular 
Af^TEUTES  ar«  associated  with  and  corresponding 
AmTo  TF’ITE-V  A I tjvs  . 


8.8.6  Proper  t jes  Com  pleteness  Checks 

’lone  cf  the  properties  are  ’’necessary"  for  a complete 
description  as  it.  is  up  to  the  organization  to  impose  an  v 
retirements  to  what  type  cf  properties  are  to  be  incorporated 
in  the  docum «nat ion  . , 

However,  everv  property  object  defined  should  be  used  at  least 
once . 


1)  Every  KFYWORP  should  APPLY  to  at  least  one  object. 

2)  Every  A T T’’”  3’»Tir  should  APPLY  to  at  least  one  object. 

8)  Every  MpMO  should  »PPT.Y  to  at.  least  one  object. 

h)  Every  30’”’CP  should  he  the  source  for  at  least  one  object. 

c)  Everv  SECURITY  should  be  referenced  in  at  least  one  object. 
6)  Everv  TP»CF-KEY  should  be  referenced  by  at  least  one 
ob  j ect. . 
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2.9  Project  Management 

All  object  and  statement  facilities  in  UPL/CPA,  which  are 
intended  to  improve  organisation  and  management  within  the 
project  and  present  information  about  the  project  describing  the 
system,  is  referred  to  as  Project  Management. 


2.9.1  Prolec t Management  Objects 

RROBLFM- DFPTEEF  - an  object  responsible  for  the  URL 

description  of  one  or  more  of  the  objects 
heing  described.  Usually,  the  OPL  names 
will  be  the  name  of  a person  in  the  form 
normally  used  in  the  organization. 

MAIL BOX  - an  object  which  identifies  an  address  by 

which  information  may  be  sent  to  a 
particular  PSOBLEM-DEFINER . In  time 
sharing  systems,  which  provide  such  a 
service,  the  MAILBOX  would  be  the 
PFOBLEM— DEFINER's  ID. 


?.°.2  Protect  Management  Relationships 
RESPCNSI BLE- PR08L  EM- P EFINEF/RESPON  SIBLE  FOR 

A PROBLEM-USE INS?  may  be  PFSPONSIBLE  for  the  description  of  any 
other  object,  and  any  object  may  have  a 
PFSPONSIBLE- PROBLEM-  D^INEP  . 

"ATLBCX/APPLIES 

A PFOBLEM- DEFINE?  may  have  a MAILBOX  and  a MAILBOX  may  APPLT  to 
a RROFLEM- DEFINES. 


2.9.3  Project  Ma  nage  men''  Svn  ta  x and  Semantics 

"he  obiects  and  relationships  involved  in  describing  he  prolect 
management  aspect  of  a system  are  shown  pictorially  in  Figure 
2.9.3  and  in  tabular  form  in  Table  2.9.3. 

"he  PESrnNST  BLE- PpODT  FM-DEFIN2F  statement  implies  that  th»  given 
PROB I. Fv- DFRT  N SP  accepts  responsibility  for  the  URL  description 
of  the  designated  obiect;  it  is  assumed  that  any  questions 
concerning  this  description  can  be  handled  bv  the 
PROB LFM- D F^I V EF.  A given  object  may  have  only  one 

,,?SPONSBTLt’-PP0RLpM-R'FEINEP,  hut  a F 30BL EM-D SPIN EF  may  be 
RESPONSIBLE  for  many  object  descriptions. 

A "POBLFM-DEFTNER  may  have  only  one  MAILBOX,  but  a MAILBOX  may 
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APPIY  to  any  number  of  PPOBLFM-rEFTNFBS. 


4- ♦ 4 -4  4-- 4 

|Obiecfs  'V-h-'rl  w"SnOW<!IPI.f-  | | | | 

|than  r.' ILBPV  ,f  ppoRL1?w-D^FTN,:'P->|  PF0BLFr-|  ’1  AILROX  I S- >|  M AIL  BOY  | 
|nT3PRi;rv_  K-^FVPO-J^TPIE  FOB  I DEFINER  I <- APPLIES  TO  | J 

| PE^INFP  I | | | | 

4 4 4-~  -—-4  4—  — — —4 


Figure  2.9.*  'JPT  ^ a^oment  s for  Describing  Proiect  Ranaaenent 


O*:hor  Objects 


'xcpnt  Froblem 

T'f  f i n»r 

Problem 

Definer 

Mailbox 

ether  Objects 

RE5PONSIBLE- 

PROBLEK- 

DFFINEP 

Problem  Definer 

!,rS  °ONST  BLE  FOP 

MAILBOX  I! 

"'ail  hex 

APPLIES  TO 

'’’able  2.9.3 

URL  Statements  for  Describing  Proiect  Management 

2.°.  4 nrojec  * ^Ha'iemen^  Common  Eguj  valents  a r.  1 U sag  e 

meanim  of  t.h.es“  terms  are  the  sane  as  those  in  coamon  use. 
These  statements  are  intend^-)  to  help  the  project  management, 

"he  implement  a "-ion  (i.e.,  their  use  in  a particular  project) 
depends  on  the  particular  situation  and  the  standards  in  use  in 
the  craarixa  tiop  . 

2.9. s Project  Management  out ou t s 

Information  relevant  to  project  management  can  be  presented  in  a 
P0’>!*ATTFp  apple  t"*  STATEMENT  for  appropriate  PROBLEM-  DE*I  HEPS  and 
v ATI FCYFS. 

The  BATA  BASF  srp*M*py  report  qives  the  number  of  each  objects  of 
each  *ype  that  have  t>een  defined,  and  how  many  have  SYNONYMS  and 
b^SE RirTIONS . "his  report  can  he  used  by  the  project  leader  to 
review  the  degree  of  prooress  in  the  project. 
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2 . ° . * Project  Pa nage ment  Comrletoness  Checks 

1)  Every  PEOPL  SM-U EFI VER  should  he  RESPONSIBLE  for  at  least 
o" e object. 

-)  Every  object  should  have  one  and  only  one 
FES  POPS  t FT,E  ■*P",o  R LEM  - DEF  IN EF  . 

1)  pvery  MAILBOX  should  APPLY  to  at  least  one  PPOBLEM- DEFINER. 
4)  Fverv  PFOBt,  EP-DEFINEF  should  have  a MAILBOX. 
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1.  UPL  F YN  T A.  X AND  SEMANTICS  BY  TYPE  OF  OBJECTS 


The  full  and  detailed  syntax  of  OF  I is  contained  in  Part  II  of 
1 this  document.  There,  Section  3 contains  a summary  of  the 

statements  in  each  section  with  the  sections  in  alphabetical 
order.  Section  4 contains  the  description  of  each  statement, 
within  a section,  statements  appear  in  alphabetical  order  by 
statement  name. 

Ir.  this  section  the  Sections  and  Statements  are  presented  in  a 
different  ord«r.  "te  paragraphs  following  each  statement 
describe  the  statement  and  give  the  syntax  for  each  statement 
and  an  example  of  *heir  usage. 

As  in  Section  ?,  the  explanations  of  OPL  statements  include 
three  levels  of  precision: 

"must"  - denotes  that  this  is  checked  by  UFA  and  not 

entered  into  the  data  base  unless  correct. 

"should"  - denotes  that  this  is  not  checked  by  UFA  before 

scored  in  the  data  base  but  is  necessary  for  a 
complete  description  of  the  target  system. 

Some  of  these  "completeness"  checks  are  made 
when  producing  UP  A reports  and  warning  messages 
are  produced.  Others  can  be  made  by  the 
analyst  usinq  U"a  reports. 

"implies"  - denotes  tha  semantic  meaning  of  the  statement. 

and  This  is  not  checked  by  UP. A nor  necessary  for  a 

"may"  complete  description.  Interpretation  is  to  be 

decided  by  the  Problem  Definer  and 
org  anization . 

I'he  urt  reserved  word  in  parentheses  after  the  syntax  notation 
for  a statement,  specifies  an  acceptable  abbreviation  for  the 
lone  form  of  the  statement’s  reserved  word(s). 

”he  word  "s  jetton"  is  used  in  UPL  to  denote  a number  of 
statements  an*  in  this  paper  tQ  denote  a number  of  paragraphs. 

"o  avid  confusion,  the  fist  letter  will  be  capitalized  when 
i referring  to  a ” " t Section. 

J 

i 

d . 1 Order  of  Presentation 


! 

; 

i 


| 


PA" 


I USE?  FFCniPEMENTS  LANGUAGE  FAN  UAL 


H61  PO/MULTICS/URT  USSR'S  MANUAL 


123 


3 . 1 . 1 n r d or  o^  the 

"h  o res*  of  "-action  1 soecifies  the  complete  syntax  of  the 
statements  for  each  rT i?i  Section.  The  (JF L Sections  are  presented 
in  the  order  shown  in  "able  1 . 1 . 1 . 

3.1.2  Order  of  statements  within  a Section 

The  facilities  of  MM  t.o  state  an  information  processing  problem 
have  been  Inscribed  in  section  2 in  order  by  a sequence  of 
different  aspects,  "he  particular  sequence  chosen  is  a natural 
one  in  which  to  learn  the  lanjuage.  It  is  also  a natural  one 
wh»n  the  problem  is  beina  defined  in  too-down  fashion.  In  this 
section,  within  each  fJPL  Section  description,  the  corresponding 
'IBL  statements  a:’  ordered  according  to  the  asDect  of  the  system 
description  to  which  the  Statements  apply.  The  aspects  of  the 
system  descriotion  are  given  in  the  following  order: 

System  Plow 
System  Structure 
Data  Structure 
Data  Derivation 
System  size 
System  Dynamics 
System  Architecture 
Systpm  Properties 
Project  Management 

Since  System  ^roDerty  an*  Project  Management  statements  can 
anpoar  in  almost  every  section,  they  are  given  only  once  in  3.2. 

Regardless  of  the  order  in  which  statements  are  entered  into  the 
M?A  data  base,  they  appear  in  the  ^OPMATTFD  PROBLEM  STATEMENT  in 
a s^ardar*  ord°r.  "he  order  is  essentially  that  followei  in 
section  2 and  summarized  ir  Table  3.1.1.  (The  order  in  which 
the  sections  (i.e.,  the  types  of  objects)  appear  in  the  report 
is  ♦‘he  cne  ir  which  the  types  of  objects  were  listed  in  the  fila 
used  as  the  input  to  the  NAME-GEN  command  and  to  produce  the 
e0n*A"TFP  ™"QLEM  STATEMENT.) 
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INTERFACE  or  TEA  L-WOF  LP-F  N^T  TY 

3.  3 

T N PMT 

3.4 

orj’,,nr;T 

3.  5 

p n r i T y 

3.  6 

set 

3.  7 

°ELA  TTON 

3.8 

groups  an  1 ELEMENTS 

3.9 

PROCESS 

3.  10 

TN  TEF VAL 

3.  11 

CONDITION 

3.  12 

FVey  <t 

3.  13 

PROCESSOR 

3.  14 

”ESn  UPC17 

3.  15 

RFSOnFCF-OSAGE-P  ARAM^TFR 

3.16 

UNIT 

3.  17 

PR03  LPT- DFFI N EP 

3.  18 

MEMO 

3.  19 

DEFINE 

3.20 

ATTRIBUTE 
ATTRIBUTE- V ALU F 
CT  ASSIFTCA  TION 
V?  Y WOF  D 
MAILBOX 
SECURITY 
ROORCF 

SU  9SFT'rT’JR-C,5Tn,FFIOV 
SYSTEM- PA  RASTER 
ACF- KPT 

DESIGNATE  3.21 

SYNONYM 


Table  3.1.1  Order  of  ORL  Section 


3*2  ItalSlSais  ?2E5iti«d  in  AiJ£§t  SlSLI  ML  lSSli2fl 

■’“ho  URL  statements  that  may  be  allowed  in  a given  fJRL  Section 
ar **  deoend®nt  on  the  types  of  objects  defined  by  the  section 
header.  Where  it  is  illogical  to  say  that  an  ELEMENT  OSES  a 
PROCESS,  to  state  that  a PFOCESS  OSES  an  ELEMENT  would  be 
allowed . 

There  are,  however,  the  OF1  statements  related  to  System 
°ropetties  and  ’’rolect  Management  that  can  be  used  within  alaost 
any  Section.  These  statements  are  described  in  this  subsection. 

3.2.1  SYNOVJW  Tta^ement 

SYNONYMS  are  alternative  names,  or  abbreviations,  that  may  be 
used  •■o  reference  a particular  object  name.  SYNONYMS  aust  be 
unaiue  within  *h®  problea  stateaent,  though  an  object  can  have 
anv  number  of  SYNONYMS. 
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Svnt  a x : 

SYNONYwS  (Svij)  

(list  of  synonym  names) 


Example: 

’Jor  a lonq  nan«  li^e  "d^partments-and-employees,"  it  may  be 
easier  *■  o reference  it  by  specifying  short  synonyms: 

SYNONYMS:  dept-erap,  de; 

3.2.2  bF  SC7 1 P*T"r0  *'  fia foment 

""ho  DESCPIPTICV  statement  allows  the  problem  definer  to  specify 
information  about  an  object  in  a narrative  format.  There  are  no 
restrictions  or  what  is  allowed  in  the  narrative  description 
excop*  that  a semi-colon  cannot  be  used  inside  since  it  is  used 
to  denote  t-he  end  of  the  statement.  Any  number  of  DESCRIPTION 
statements  may  be  given  for  an  object,  but  all  are  combined  into 
one  DESC PI’1? T0N . Any  subsequent  DESCRIPTIONS  are  concatenated 
to  the  current  DFFCPTPTTON. 

Syntax: 

0re-->OTp-T0»j  (n^cr)  ; 


(narrative  description) 


Example: 

to  describe  tj,«  hiqhest  level  FPCCESS  in  the  system  being 
described,  th°  following  DESCRIPTION  statement,  may  be 
apol  icablo: 

DESCRIPTION; 

"■his  is  the  highest  level  process.  It  accepts  all  input  to  the 
svster  and  nro^uces  all  outputs.  ; 

■».  2.  3 HI  Him  St  a+enent 

"he  KFYVOpg  statement  car.  ba  used  to  logically  relate  object 
names  together  for  retrieval  and  subsequent  analysis  purposes. 
An  obi»ct  may  have  2ry  number  of  KEYWORDS. 
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rynt a*: 

«'FYWOPr  (KET) 

,?jram  pl° : 

the  following  st  atement  may  b»  used  to  identify  particular 
dpocESSFS  as  low  ;st- level  processes: 

FEYVOPD:  TERMINAL; 

All  ppoc^rFS  the  KEYWUF  0 "TERMINAL"  can  be  subsequently 

retrieved  ton^ther  ard  analysed  in  available  ORA  reports. 

■> . 4 AZZJ&BHIZ!  StaifZLSCi 

ATTRIBUTE*  ar«  used  to  state  specific  characteristics  of  qiven 
obdects.  '"he  f '"'T’P,'E?  UTI  rane  designates  the  name  of  the 
char  actrrist  ic  and  the  ATTRI BUTE- VALUE,  the  value  or  magnitude 
of  this  characteristic.  The  ATTRIBUTE- VALUE  may  be  either  a URL 
name  or  an  irteqor. 

An  o h dec t *a»  have  ary  number  of  ATTRIBUTES.  A given  ATTRIBUTE 
can  refet  to  arv  number  of  ob-jects  not  necessarily  of  the  same 
type. 

Svnt  a x: 

B t n*t>  y pt’T  EE  ^A’T”r'**)  f 

attribute  name  attribute-value  name 


(list  of  keyword  names) 


attribute  name 


attribute-value  name 


attribute  name  attribute-value  name 

*xaip  plet 

To  snecifv  that  a particular  lata  element  is  numeric  field  of 
length  sir,  th«*  following  statement  may  be  used: 

ATT PX BUTS:  ’YPE  '^"EPIC, 

LENGTH  SIX  { 
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7.2.?  ASSERT  Statement 

The  ASSERT  statement  allows  the  Problem  Definer  to  assert  that 
one  object  must  have  a particular  ATTRIBUTE  and  ATTRIBUTE- VALnE 
when  related  to  another  object.  An  oblect  may  have  a number  of 
ASSERT  statements. 

Synt  ax: 


ASSERT  ( ASPT)  

(list  of  names  followed  by  attributes 
and  at  tribute- values) 


Exam  Die : 

If  PPOCF5S  get-name  DEPIVES  name  USING  number,  an  appropriate 
ASSEPT  statement  would  be: 

ASSERT:  name  ♦•ype  char, 

number  type  integer; 

7.2.6  PS  SPO N SI3LS-PP  OBI.EM-USETNER  Statement 

The  RESFONST  B LE- pnog  LSM-D  EFI  NEE  statement  specifies  that  one 
problem  definer  person  is  responsible  for  initial  preparation 
and/or  maintenance  of  an  object  description.  Only  one  problem 
definer  may  be  delegated  responsibility  for  a given  Section,  but 
may  he  resnonsible  for  more  than  one  Section. 

Syntax: 

R^SPONSI  BILF-  PPO  BLF!“!-  D7F  T NEF  (RPD) ; 

(name  of  responsible- 
probl  em-def  iner) 


Fxamole: 

’’’o  soeci  f y that  vichel  Bastarache  is  responsible  for  the  n RL 
description  for  a particular  object,  state: 

RES  PONS  TF'LF-  PFOBLFM-DEFINER  MICHEL- BASTARACHE; 

in  the  PPL  Section  for  that  object. 

7.2.7  SZZzZlZ.2 

"he  STF-MEMO  statement  allows  a description  common  to  several 
objects  (and  available  in  a MEMO'S  DESCRIPTION)  to  be  , 

referenced.  ’’’his  statement  may  occur  any  number  of  times  for  a 
aivtn  obiect. 

Svn*  ax: 


P A ~? 
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v|?mp  (-?•») 

rxaro  ole: 


(list  of  memo  names) 


■’’o  refer 

rslovant 
Fol 1 owir 


to  a particular  f'^MO  on  programming  conventions 
to  th®  de.scription  of  low  level  PROCESS  PS , the 
a mav  bo  given: 


PROGRAMMING-CONVENTIONS; 


1.2.8  ^PHFCr.  Hta.tej.2Bi 

"he  SOURCE  statement-  identifies  information  not  contained  within 
the  svs*®m  docum  jr.ta t ion  that  is  relevant  to  the  understanding 
o F * he  sys^m.  The  source  may  be  a person,  a document  (such  as 
a nractice  or  aa  idel  ine>  , etc.  Any  number  of  SOURCES  may  be 
relabel  to  an  obirct. 

Svht  ax: 

source  (SS")  ; 

(list  of  source  names) 


^xam  pi e : 

"o  mabe  re^erenc?  *0  a naper  written  by  Constantine: 

SOURCE:  CONSTANTINE; 

"he  UFL  description  of  the  SOURCE  name,  CONSTANTINE#  would 
nrobahlv  specify  relevant  information  such  as  name  of  paper, 
date  published#  etc. 

? . 2 . 9 SECURITY  StatSneBi 

The  SEC  UP  I"  Y sFa  *-emer.  t specifies  the  level  of  security 
associated  wiFh  a given  object's  UFL  description.  Any  number  of 
SECURITIES  may  be  related  to  aft  ob-ject. 

Synt  ox: 

SFCUer-y  (SEC)  ; 

(list  of  security  names) 


Example: 


"o  speci  fy  that  the  U&T  description  for  a given  object  may  only 
be  viewed  bv  company  personnel#  the  following  statement  may  be 
used  : 

SECURITY:  COMPANY; 
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■*.2.10  ZlhJZLzlll 

A '"N  A CF-  KrY  is  used  to  correlate  oblects  which  exist  in 
diff=»rert  data  bas»s.  An  object,  may  have  several  TPACE-KEYS. 


?vnt ax: 


"PAC'-KFY  (""  K ~Y)  

(list  of  trace-key  names) 


Example; 

-he  security  l«v ’1  in  a loqical  system  design  data  base  and  a 
security  level  number  in  a physical  system  design  data  base  may 
both  have  the  sta*<=men*: 

?CACF-KEY:  security-level-key ; 
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3 . 3 INTERFACE  Se  ot  ^0  n 

wEAL-Wo»id- ENTITIES  or  INTERFACES  are  named  oblects,  outside  the 
target  system,  that  interact  with  the  systea  beinq  described. 

If  the  system  b°inq  described  was  a payroll  systea,  one  possible 
INTERFACE  would  be  the  employees  paid  by  the  systea.  They  could 
be,  ir  one  sense,  the  custoaers  of  the  system. 

INTERFACE  (TNTF)  ; 

(list  of  interface  names) 


3.1.1  ^ystom-  Flow  Ut§teme£ts  fox  I NTHSFACES 

■"he  DECEIVES  statement  is  used  to  specify  that  the  INTERFACE 
accents  information  (OUTPUTS ) from  the  target  systea. 


’’FCEI  Vec 


(PCV*) 

(list  of  output  names) 


■"O  specify  t h ? manner  in  which  INTERFACE  receives  OUTPUTS  more 
precisely,  the  HE °IN DTVG  OK  and  EOF  EACH  clauses  may  be  used  in 
coni unct ion  with  the  rec^IV^S  statement. 


nor p y y rc 

(list  of  output  names) 

P^FNIING  ON 

(list  of  elements,  condition-names) 

FOE  EACH ; 

(list  0f  entity,  input,  output,  qroup, 
element,  set-names) 

'"hr*  (!PMTSAT"':  statement  is  used  to  specify  that  the  INTERFACE 
produces  information  (INPUT)  which  is  used  by  the  system. 

OE  *J  r n A "■  E S (TENS)  ; 

(list  of  input  names) 

■"o  specify  the  manner  in  which  INTERFACE  qenerates  INPUTS  more 
nrecis°lv,  tho  0307x1!'’?,  ou  and  EOF  EACH  clauses  may  be  used  in 
coni  unction  with  the  GENERATES  statement. 


GEN  r r>  ate  3 


(list  of  input  names) 


pnorxjrsTfc-f;  _ 

(list  of  element,  condi tion- names) 


FOR  EACH ; 

(list  of  entity,  input,  output,  group, 
element,  set-names) 
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Th  PFSPONSI  FT,17  statement  specifies  that  an  INTERFACE  has  the 
renDcnsihil i t y of  maintainin'!  information  (SETS)  within  the 
target  system. 

pronf'KOj  (poo  p) 

(list  of  set  names) 

To  insuro  completer®?*;  of  the  problem  statement,  the  problem 
definer  should  check  that  every  INTERFACE  either  GENERATES  some 
INPUT,  cECrIVTR  some  OUTPUT  or  is  PESP0MST3LE  for  some  SET. 

An  t qnrc  FACE , * h eref ore , can  interact  with  the  system  only 
throuqh  RECEIVING  eu"prjT'Sf  GENERATING  INPUTS  or  being 
^fspcnfi  °LT  *0®  SC”,’S  . In  particular,  it  is  not  possible  to 
describe  any  processing  performed  in  the  INTERFACE.  If,  in  the 
svsnem  description,  it  is  necessary  to  describe  processing  in 
the  INTEPFACF,  then  it  should  be  designated  as  a PROCESS  instead 
of  an  TNTEtEAC®.  See  section  4.1  on  system  boundaries. 


3.3.?  System- Structure  at  emends  for  INTERFACES 

An  I NT-!®  17 ACF  may  be  par1  of  one,  and  only  one,  larger  INTERPACF, 
and  it  may  havc  arv  number  of  subparts  that  are  also  INTERFACES. 


PAP"' 


(interface  name) 


F'inpARTS  (Srjpo) 


(list  of  interface  names) 


■"hese  statements  permit  organization  structures  to  be  specified. 
This  can  be  used  to  obtain,  from  UFA,  descriptions  of  the  system 
as  seen  from  a particular  part  of  the  organization. 


3.3.3  Data- Derivation  St  at.ements  f cr  TNT  EFFACES 

In  the  target  system,  an  INTERFACE  may  have  the  right  to  access 
information  of  certain  classifications  and  categories. 


SECn?I?Y-ACCT 


rTOMT  (SAP) 

(list  of  classification  names 
optionally  followed  by 
classification  levels) 


3.3,4  Pro1ect-*a  n a go  went  Statements  for  INTERFACES 

"he  RESPONSIBLE-  Pf 03LEF-EEPINEP  statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
sect icn  3.2. 
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3 . 3 . S Sy  stem- Pro  r>ert  j.es  Statements  for  I \TEP  FACES 

^he  SYNONYMS,  T'SSCPI  PTION , SEE-KEKO,  KEYWORDS,  ATTRIBUTES, 

r^cUFTTY,  SOURCE  and  TFACF-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3.2. 
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3.  a T NPni  Sec*ion_ 

TN?P'TS  are  ir  formation  that  is  produced  (CFN^FATED)  by 
TV"’7  “FACE'7  ard  that  is  brought  into  (RECEIVED  BY)  the  tarqet 
svst  Pin. 


TNPnn  (-NP)  ; 

(list  of  input  names) 

The  name  ot  the  T,,7,UT  car  be  considered  as  the  name  attached  to 
either  the  collection  of  i values  or  the  physical  medium  on 
which  the  data  values  are  recorded,  i.e.,  the  carrier  of  the 
data  values,  or  to  both. 


’.a.  1 P vs  tom-  rlow  ^^ato^ents  f o_r  INPUTS 

The  names  of  the  77  ~F  ACr"  providing  the  INPU"  are  given  in  the 
CFVT’DATrP  s*  a t-.m  er-  . 


QpvPKB-YP  r>Y  (COUP)  ; 

(lisf  of  interface  names) 

"o  sppci  fv  t h .a  manner  in  which  an  IK  PUT  is  generated  more 
precisely,  the.  DEPENDIN'!  ON  and  FOR  EACH  clauses  may  be  used  in 
conjunction  wi*h  the  ci'NESA‘nEO  BY  statemert: 


O-TN  E P ATT  D nY 

DEPEND"  NO  ON 


(list  of  interface  names) 


(list  of  element,  condition-names) 


FD»  EACH ; 

(list  of  entity,  input,  output,  group, 
element,  set-names) 

"he  object,  ir  the  system  which  accepts  the  INPUT  is  given  in  the 
° EC  F!  T V r P RV  statement: 

r ?C " I VFT  3 Y (=CNn)  ; 

(list  of  process  name'1-) 

"o  specify  tfo  » ivnar  in  which  an  INPUT  is  generated  more 
nr«cisel  v.  "he  P"Pr  N DTNO  ON  and  FOP  EACH  clauses  miv  be  used  in 
condunction  with  the  "FCFIVED  BY  statement. 


RECEIVER  nY  _ _ 

(list  of  process  names) 


T'ET’FNEINO  O'! 


(list  of  element  condition- names) 
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FOP  EACH  

Tlisfe  of 

ent  i t y/i nput /out pat /group/element/set-na  raes) 


"hpse  statements  refer  only  to  the  logical  collection  of  data 
elements  value,  ard  nrovide  a way  of  stating  where  the  INPUT 
comes  from  and  whav  PROOFS*  must  accomplish  whatever  is 
necessary  * o "accent"  it.  Ml  operations  on  the  data  element 
values  *tis+  he  r, npc.i  fied  separately  in  the  definition  of  the 

ppoc  esc  # 


rver  v TNP'r  should  he  GEN  FPA'T’Fn  by  at  least  one  INTEPFACE  and 
PECETVTP  by  at  1 pan*-  one  PROCESS, 


3.4,?  System-  structure  5 t^t  aments  for  IN  PUTS 


An  zrprr  mav  h«  Dart  of  ore,  and  only  one,  larger  INPUT,  and  it 
mav  have  any  nurnhei-  of  suhparts  that  are  also  INPUTS. 


° ap  r 


(name  of  input) 


."'Hf'Ar'' p (SiJP^) 

(list  of  input  names) 


""hose  statements  allow  definitional  structures  (grouping  INPUTS 
together  t0  ca1!  than,  by  a sirgle  name)  and  high  level  data 
structures  to  v)0  specified.  ''‘he  lowest  level  of  INPUTS  normally 
will  to  us^  for  physical  documents,  messages,  cards,  etc,,  that 
flow  into  the  system. 


"’o  describe  a collection  of  INPUT  occurrences  (SFT  of  INPUTS), 
the  CCNT  A TN  E u statement  may  hi  used  to  relate  INPUTS  to  SETS. 

CON*  nrvEE  ( C NT))  ; 

(list  of  set  names) 

"’his  SET  can  ‘■h=>n  he  used  in  further  statement  of  requirements, 
This  irinht  be  used,  for  example,  to  describe  a batch  of  inputs 
such  as  tine  cards  which  are  to  be  treated  as  a unit  for 
orocessi ng. 


An  INIF""  car  be  contained  in  any  number  of  SETS. 


? . 4 . ’ Pa  * a- Structure  St.  at  ement  s for  INPUTS 

The  data  (GPOUps  an  1 FLEFENTS)  whose  values  appear  on  an  INPUT 
are  defined  via  the  CONSISTS  statement.  Each  data  name  used  in 
the  statement  ran  he  optionally  preceded  by  a SYSTEM-PAR  AF.ETER 
to  defire  th*  number  of  occurrences  of  the  data  value  that  may 
anpenr  on  the  INPUT.  The  CONSIST*  statement  only  specifies  the 
data  cn  the*  THRU’"  ard  implies  nothing  about  format. 


P Ar- 
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CONSISTS  (CSTS) ; 

(list  of  aroup  and  element 
«ach  name  optionally 
presented  by  a system- parameter . ) 

A complete  problem  statement  should  have  all  INPUTS  (which  do 
not.  have  SUPT>AT»TS  statements)  broken  down  into  5 ROUPS  and 
’'LEM  ENTS  . 


3.4.4  Da  ta-D  erivati or  Sta  temen  ts  f cr  INPUTS 

Tho  U S?P  statements  specifies  those  PROCESSES  which  use  the 
information  available  in  the  INPUT. 

USED ; 

(list  of  process  names) 

"his  implies  *-.ha  t a t least  one  piece  of  data  (GROUP  or  ELEMENT) 
on  the  INPU"  is  heinq  USED.  To  specify  the  manner  in  which  the 
T V ° U T is  used  more  precisely,  the  DERIVE  or  UPDATE  clause  may  ba 
used  in  conlunction  with  the  USED  statement. 

US*D  EY  

(lis*  of  process  names) 

"0  DERIVE  ( Dc  V>  ; 

(list  of  element,  qroup,  entity, 
set  and  output  names) 


qqrr,  PY _ 

(list  of  process  names) 

"0  r' PD  ATE  (UPP) ; 

(list  of  element,  qroup, 
entity  and  set.  names) 

Tr  INF'"  m,y  he  US'D  by  any  number  of  PROCESSES.  Every  INPUT 
eboul'1  bo  used  *iv  av  l^ast  on?  PFOCESS. 

"bo  CT  AESIVTC  rrow  af  an  I^U?  may  be  specified  with  the 
CT.A.C  «IFrCATTCM  stamen* : 

(list  of  c1  assf ica^ion  names, 
each  optionally  followed  by 
a level  number) 

An v PROCESSES  or  r>? OCESSr FS  that  use  the  INPUT  must  have 
SECURITY—  ACC  "US-  RIGf'TS  that  match  the  classification  of  the 
INPUT  . 
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3.4.  R -3  v ste  m-  o y n a mi  c r.  *t,a_remen.ts  for  T*»  P NTS 


"or''1  *han  orr  individual  instance  of  an  INPUT 
snir.  period  of  ti.no,  mhe  number  of  instances 
occur  over  *■  imo  is  stated  through  the  HAPPENS 


mav  occur  over 
of  the  INPUT  that 
statement: 


ji*po*ns  (d>p)  

tsvs*  em- nar am e”er ) 

YET-p^e  rnr'*T)  

(interval  name) 


EV*FY 

fsvs *•  am- pare  mete r)  (interval  name) 


[ NTT  HIV  1 AFTER ; 

(sv  rto#-  nar  ame*  r r)  (interval  name)  (event) 

pverv  IK  PH-'  shoull  havn  a HAPPENS  statement. 

The  arrival  or  a r>.  input  may  affect  the  processing  currently 
being  oerforn11’,  or  it  may  initiate  new  processing.  ""his  is 
described  via  3 "'~TUgpRS,  TERiYINATFT  and  INTERRUPTS 
stateraen  ts: 

'"^TORERE  (T,r,?S)  ; 

(l  is*  of  process  names) 

(list  of  process  names) 

ppp^r  (I  *r~) ; 

(list  of  process  names) 

""he  r*7Pr N’V' n c gn  and  ROr-  vac  1 clauses  can  be  used  in  conjunction 
with  the  TPTr.rjrgs,  T T’FTIK  A"*n?  and  INTERRUPTS  statements. 

""be  arrival  of  » n IN')Tr  mav  also  cause  an  EVENT  or  set  the  value 
of  a CCN ET"’TO N. 

CAUSES  (Css)  . 

(list  of  event  names) 

mSKT0  (YAK)  _ _ TFUP  (T); 

(lis*-  of  condition  names) 

M A T®  S (K  ' ?)  P ALS  E (?)  ; 

(list  of  condition  names) 

"^e  DEPENDING  r>N  and  for  vaci?  clauses  may  be  used  in  conjunction 
wi*h  the  CAUSES  a**  "jipjc  statements. 

* n TUPrjv  mav  or  mav  rot  be  involved  in  a nv  system  lynamics 
re  1 a * ior  ships. 
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Projec*  JlllHf menr  Statements  for  TN?;j? 

-1,^  nf  *t*ov*~  »L3-  p^orl  ?:--n -PIS^R  statement  raav  be  used  in  this 
tecMcn.  ner^rioMon  and  syntax  of  this  statement  are  liven  in 
sec4-  i or  3 . "> 


7 * ^ . 1 s*:em-  ° ro  per  M eg  S tat emends  for  I N PUTS 

Th*  SVNnvY':S  , DFSr«»I  PTIOP,  SEE-MENO,  KEYWORDS,  ATTFIBUTES, 
'ry?'l,  3 ECU°I~Y,  S3  npcv  and  "FACF-KFY  statements  may  be  used  in 
*his  section.  Description  and  syntax  of  these  statements  are 
civ  on  in  section  ?.  2 . 


* 

' 

! 

' « 
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"> . S 0 TTt>*i?  I^c^ion 

PT"P’JTS  ar°  information  that  is  produced  (GENERATED)  by  the 
target  svst«m  (ppnrr FEES  within  the  system)  and  that  goes  to 
(ar«  SFr-,Iir:p  ny)  TNT  EFFACES  . 

0’T?t>U?  (01P) ; 

(list  of  output  names) 

mh ° name  of  t h*  OH^PHT  can  be  considered  as  the  name  attached  to 
either  or  fhp  collection  of  data  values  or  the  physical  medium 
on  which  the  lat  a values  are  recorded,  i.e.,  the  carrier  of  the 
data  values  or  * o both. 


3 . S . 1 System- plow  "t  at enent  s tgr  0 PTPUTS 

"ha  names  of  *-v.e  p?oc ’re'ST  S producing  the  OUTPUT  are  given  in  the 
o ? N T FA'!'FT)  st  a **  em  ° n *■  . 

ns'i~p,'TEri  3Y  (c”'r'(  _ 

(list  of  process  names) 

"o  specify  the  manner  in  which  OUT F UTS  are  generated  more 
precisely,  t h®  D"??*’ rTk«»  ny  and  fob  EACH  clauses  may  be  used  in 
coniunction  with  th»  GFW^STEU  PY  statement. 


t'IF7 Mf TN 0 "*y 


(1 . is*-  of  element /con  1 i tion-na  mes) 


^OP  FACH 


(list  of 

jnt.  i t v /i  npu  t /out  n ut/n  roup  /element/set-  names) 

mh«  I*TT’nF’'?r,!  whi-'h  accept,  tae  OUTPUT  are  given 
s*atfmen«-  ; 


in  the  RECEIVED 


^('rtvtr  sv  (S^VD)  

(list  of  in*erface  names) 

To  sneci fv  the  manner  in  which  OUTPUTS  are  received  more 
nreciselv,  vh®  OTP^NETNO  ON  and  FO^  EACH  clauses  may  be  used  in 
con  1 urc*  i o”  vi*h  *h®  FFCF.7VED  EY  statement. 


"FENCING  IK 


(list  of  eleraent/rondit.ion-namesi 


eon  "J»OH 

(list  of 

e n *■  i * y/i  nmi*  /out pu*  / group /el ement/set.-na  mt3) 


’h  ‘S®  s«- atemr  n*-s  refer  orlv  to  the  logical  collection  of  lata 
“laments  values,  arid  provide  a wav  of  statinq  what  PROCESSES 
mu3*  produce  tha  on- r ij"  * nd  where  it  must  be  transmitted  to. 


pv 


T 
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All  croravions  on  thr  da*a  clement.  values  must  be  specified 
separately  in  Mi->  1 r>  f in  it  ion  of  fh°  PROCESS. 

rv"r  y OMTPin  should  be  TTN?15  ATE  D by  at  least  one  PROCESS  and 
^ECCTVEP  bv  at  leas*-  onp  Tfi'j'rpFACF . 


I.o.?  3 y st  on-  Struct  nre  Statements  fo  r OUTPUTS 

An  OTi'rnrt’7  may  ho  nart  of  one,  and  onlv  one,  larger  OUTPUT,  and 
it  may  have  anv  number  of  subparts  that  are  also  OUTPUTS. 


PAR" ; 

(rams  of  output) 

^'TUPATTS  (srtFn)  _ ; 

(list  0f  outpu*  names) 

"hase  sta-ements  allow  definitional  structures  (grouping  OUTPUTS 
tou^ther  to  call  them  a single  name)  and  high  level  data 
structures  to  specified.  "he  lowest,  level  of  OUTPUTS 
normally  will  b«  us^d  for  ohysical  documents,  messages,  cards, 
"tc.,  that  clow  out  of  the  system. 

"o  describe  a collection  of  OUTPUT  occurrences  (SETS  of  OUTPUTS) 
the  eC^ATUpr  statement  may  be  used  to  relate  OUTPUTS  to  SETS. 


C0NTATT17T  (ONTO) ; 

(list  of  set  names) 

"his  0r'r  can  bo  used  in  further  statement  of  requirements, 

"his  iriaht  be  used,  *or  example,  to  describe  a batch  of  outputs 
that  are  to  ho  produced  as  a unit. 

*n  og'-pn"  car  be  contained  in  any  number  of  SETS. 


3.c.1  na  ta-c  tructnre  2*21  f T£l!i_s  for  OUTPUTS 

The  data  (go  rung  and  ELEMENT*?)  whose  values  appear  on  an  OUTPUT 
are  dr  fined  via  the  c ON  ST  STS  statement.  Each  lata  name  used  in 
♦hn  statement  can  be  optionally  preceded  by  a SYSTEM-PAP AMETEF 
to  iefine  the  number  cf  occurrences  of  the  data  value  that  may 
annrar  on  the  r)U"PU"'.  "he  CONSTS"?  statement  only  specifies  the 
data  cn  t^e  rrog-  ard  implies  nothinu  about  format. 

CON  SIS"?  (CStC) ; 

(list  of  group  and  element  names, 
each  name  optionally  preceded  by 
a system  parameter) 

A complete  probl  ?m  should  have  all  OUTPUTS  that  do  not  have 
c,q^T>ar>'-c  statements  broken  down  to  ".ROUPS  and  ELEMENTS. 
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”H<;  CLASST^IC 'TION  of  an  OUTPUT  nay  he  specific!  with  the 
ri.ASrT*TCA?TCN  sta*  non*-. : 

r T.  A S S I ^ J r A”  T O U ; 

(list  of  classification  names,  each 
optionally  followed  hv  a level  number) 

»nv  FrorTS3FS  or  OFOCFFSORS  that  use  the  OUTPUT  must  have 
•?TCUFT’’’*-A::C‘F'!.'>PTOHTS  that  match  the  classification  of  the 
output. 


! 

I 

4 


1 

i 

I 

I 


i 


">.c.u  ha  ta-Oerivavior  Sta  temen  ts  fee  OUT  PUTS 

’’’h'*  FFPIVED  statement,  specifies  those  PFOCFSSES  that  derive  some 
information  presented  on  the  OUTPUT, 

pyRIVF”  ( Dr  y P ) ; 

(list  of  process  names) 

"'his  statement  implies  that  at  least  one  piece  of  data  (GROUP  or 
FTTrrN~)  on  the  OUTPUT  is  PEPIVEU. 

■"o  snacifv  more  precisely  how  the  OUTPUT  is  derived,  the  USING, 
DFPFNPTG  ON,  and  FOP  FACH  clauses  may  be  used  in  conjunction 
with  the  o®® I vpP  statement. 

OFPTVFD  BY  (PRVP)  

(list  of  process  names) 

USING  

(list  of  input,  set,  entity,  qroup 
and  element  names) 

0FP2N0ING  OM  

#1  1st  0f  element,  condition-names) 

*OP  EACH ; 

(list  of  entity,  input,  output,  group, 
element,  set-names) 


1.S.5  System- oyn^mj  os  Sta  tements  f <?r  OUTPUTS 

More  than  one  individual  instance  of  an  OUTPUT  may  occur  over 
some  period  of  ♦i*»,  The  number  of  instances  of  the  OUTPUT  that 
occur  over  time  is  stated  through  the  HAPPENS  statement: 

«ApPrNS  HA?) 

( syst  em-parameter) 

TTNEF-PEP  (-’IN?)  ; 

(interval  name) 


o 
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1«1 


=:vpn  y 

l^^oTp.inuftor)’  ~ ~(j  nt  erval”name) 


r vit'^vi AFIER 

l^'N'vwruetor)  (interval  name)  (event) 


*varv  rvr*'}4*  should  have  a HAPPENS  statement  . 


3.s.P  "rolect  -”anase m^nt  Sta  t °ments  for  OUTPUTS 

*h -.  p^Epos “t  3T.”-  pr^s  I FM~r I N2  P statement  may  he  used  in  this 
Section.  Pe  fieri  n*?  on  and  syntax  of  this  statement  are  given  in 
section  3,2, 


■’.S.'7  System  - nro  ppo»  y Statements  for  0H~  PUTS 

"I14  )!ivr,  ^^rpTION,  5*»-?*KC,  KFY'WCFOS,  A"TPIBUTES, 
».'3S~i5'r,  ? ECn  P r-y  t \ "cjcf-KEY  statements  may  he  used  in 

*-his  Section,  r -»sc  r i rt  ion  iri  syntax  of  these  statements  are 
v»n  in  section  1.  "*  . 
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1 . r-  2'j.Z.lll  z2£Li'2H. 

An  * »T  y i s a coll  faction  of  information  manipulated  (USED, 
nE^TVEU  ant  hv  tv,  tarqqt  system.  An  ENTITY  differs 

fro*  ar  7M°?i'r  or  O'l'H!"  in  that  iv  is  information  maintained 
entirely  internal  *r>  t>e  system  and  car.  never  cross  the  system 
boundaries  (i.o.  , he  S'  PAT  S3  or  REC7TVIC)  . 

fMEnTS,  Ttmpr-e  ) T'r-'IZIFS  are  similar  constructs,  though  only 
"NT” TIrr  can  h«  loj’ rally  connected  through  R SLA TIOM S . 

wt* nr  — y ( y»;  'i 

(list  of  entity  nam°s) 

7n  manv  apnl  i^i*inrs,  “-he  usaqe  of  ENTITIES  is  synonymous  with 
logical  record":.  For  pxamttl?,  if  an  employee  payroll  processing 
svs*  er>  were  h n " a desianed,  tie  information  needed  about 
salaried  and  hourly  employees  miaht  be  stored  on  records  which 
would  be  defined  as  T‘NTI‘nTES. 


1 . ~ . 1 rv  st=»m  structure 

To  '•escribe  a collection  of  r‘JTTTY  occurrences  (sometimes  also 
called  a fil°\  the  CO*!’ AT  NED  statement  mav  be  used  to  relate 
'ri!T”  to  S"r3. 

Cf  A Tf‘ c T (DM""'))  ; 

(lis*-  of  set  namesi 

"his  5T"r  can  *h.>n  he  used  in  further  statement  of  requirements, 
"'his  irioht  be  use-*,  for  example,  to  describe  a file  of  employee 
records  which  are  to  be  treated  as  a unit  for  processing. 

'*  .a.'5  ’'a  *•  a- 3 true  fire  statement  s for  ENTITIES 

’he  da*-a  (roo"T’>3  and  ELEMENTS)  whose  values  appear  in  an  ENTITY 
are  defined  via  ‘ha  CONSISTS  statement.  Each  data  name  used  in 
the  statpu^-f  can  be  optionally  preceded  by  a SYSTEM- PAR  A" ETE? 
to  define  the  r jiabar  of  occurrences  of  th<>  lata  value  that  may 
appear  or  “i®  ~\",T" Y. 

""he  CCN  S I S’"*’  3‘at°a°r‘  only  specifies  the  data  on  the  ENTITY  and 
implies  poth*ni  »boufc  its  format. 

CONSTf'"?  (CST'l ; 

(list  of  group  and  element  names,  each  name 
optionally  preceded  by  a system  parameter) 

a co m c 1 ° t e problem  statement  should  have  all  ENTITIES  broken 
*own  *o  'V’Ofjns  and  ELEMENTS. 
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"o  srecify  that  each  ENTITY  occurrence  may  be  uniguely 
identified  by  one  or  more  keys,  the  IDENTIFIED  statement:  is 
used  . 

IDENtIETfd  (inn)  _ ; 

flist  of  group  and  element  names) 

The  ? El  A "ED  statement  SDecifies  a logical  connection  between  two 
EHTITIE5  . 

nEL  A 'rFD  (PEL) 

(name  of  entity) 

71  A ; 

(name  of  relation) 

This  implies  that  given  one  of  the  two  ENTITIES,  information 
from  the  other  can  be  found. 


Da  ta-Df  ri  v atior  Sta  tern  on  t s for  ENTITIES 

"he  USEE  sta  t eipnnt  specifies  those  PROCESSES  which  use  the 
information  available  in  the  ENTITY. 

M ^ ^ n- 

(list  of  process  names) 

"his  statement  imolics  that  at  least  one  piece  of  data  (GP07P  or 
nT,rr)  i"  th°  ',NTT"Y  is  being  DEED. 

"o  fv  the  manner  in  which  the  ENTI"Y  is  USED  more 

pr^ris^lv,  the  n EF I V F or  ,JPD*'"E  clause  may  be  used  in 
roniurction  wi.ty,  *v,e  USED  starment. 

(list  of  process  names) 

?o  PrrivF  ( dp  V) 

(list  of  element,  group,  entity 
set  and  output  names) 

or  '(SEP  bv  a ""DCETE  to  nnpATE  data: 

n*?ED  FY 

(list  of  process  names) 

"0  (T>0)  ; 

(liat  of  element,  group, 
entity  and  set  names) 


r a r ^ 
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"he  ?rr7VT-i  s-at  »tijp  *•  specifics  those  Pn0C£3G,?S  which  derive 
■»  inf  ori> i * ion  pr’serto.j  in  the  FNTItY. 


n^T'i  (irv  'M 


(1  ’ at  of  process  names) 


-his  s^fon-'n*’  implies  Mia*  at  l“as*  on“  niece  of  data  (G^OUP  or 
rl1r’«ENT)  in  *h“  "'riTY  is  f EPTVED.  To  sneoify  the  manner  ir. 
which  Mo  ENTT"Y  is  ^erivel  m are  precisely,  the  USING,  DEPENDING 
ON,  arl  Pit-  rv:u  classes  may  be  used  ir  con-junction  with  the 

^*5  T V~r,  • 

DPPtyrT'  ny  { «5  t»  f)  J 

(list  of  process  nameg) 

usTvr; 

('  ist  of  element,  jroup,  en*it y, 
se*  and  iron*  names) 


DEFENDING  ">M 


(list  of  el  e m =>  n * , condition  names) 


(list  o t entity,  input,  output,  qroup, 
e'emert,  srt-ramr) 


TV*  ft  on  i ro  s t at  ->mer.  * specifies  these  PROCESSES  * ha*  modified 
some  information  o-esen*ed  ir  the  ENTITY. 


UPDATE?  ffTPPP)  _ _ _ _ ; 

(list  of  process  names) 

"his  gta* “met *•  implies  Mat.  at  l*ast  one  pi“ce  of  data  (GROUP  or 
I-L -?V  t h“  EMI  ~Y  is  UPDATED. 

”0  specify  mo-«  'ir-:  i 3“  ly  the  manner  ir  which  the  ENTITY  is 
undated,  th«  TVi'.;,  ?EP'c'ME_ng  ON,  and  FOP  UCH  clauses  may  he 
ns  »d  ir.  con -jure*,  ion  with  the  •lFr'iTED  statement. 

'I’lrjjf  tr  py  f'»Dr>oj 

(list  of  process  names) 

MT*!G ; 

M ’S*-  of  element,  qroup,  entity, 
s =»*  or  iron*  names) 


r?nr  vbTVG  0*7 


Mist  of  “1  erne n t , condition  names) 


vo  o s 


(list  of  “ntity,  inout,  output,  qroup, 
“lemant,  s«t«name) 

•v“rv  ET  ■’‘T’F  d“fired  should  be  ’IMF,  DEF IVED  or  UPDATED  by  at 


? r - - 
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Toast  or  o PROCESS. 

""'i-'  ''T A S SL^T’  A ON  of  an  ENTITY  may  Ho  specified  wi^h  t.h» 

Cl  AS  'TTPICHTTON  s t at  o m on*  : 

rL’V~STwTC*?TO\’ ; 

(list  of  classification  rai»s,  each 
optionally  followed  by  a level  number) 

Apv  oFDr?SSrS  or  prccr^soec  that  use  the  ENTITY  must  have 
cccr'FTTY- nrcr 'C. that  match  the  classification  of  the 
"*t  riY. 


d . * . 4 fvs^em^Fito  ^tatfmonts  ‘or  FNIITIF S 

"’he  cfl  TN.&I, ; "y  stitera^n1  specifies  ’■he  maximum  number  of 
occurrences  of  a particular  ENT.  ' in  the  target  system  at  any 
time. 

p n TNA  I ~r~''  (CAP  0)  ; 

(system  parameter) 

Fverv  ^ N " I T Y should  have  a CARDINALITY. 


1 . H . - Syst°m- Dynamics  statements  for  ENTITIES 

Th"  volatility  statement  specifies  the  manner  in  which  an  ENTITY 
chances  over  *ime.  Cince  there  are  many  different  ways  in  which 
an  ENTITY  may  bo  change-1,  this  information  is  entered  via  a 
comment  entrv.  "h0  typo  of  information  specified  in  this 
statement  "<inht  he  tv,e  number  of  times  a particular  ENTITY 
occurrence  would  be  updated  in  a given  time  interval,  how  often 
7 M m I Tv  occurrences  would  be  deleted,  and  often  created,  etc. 

VOLA^TLT  tv  ( VOL)  ; 


(comment  entry) 

’'very  EN TI"" v -should  have  a VOLATILITY. 


T . - . c Project-Management  st.a  t aments  for  ENTITIES 

"he  ""EPON^T  PI PF0°L EV-DEFINEF  statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  1.2. 
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’ . f Sv  stem-  Pro  oert  jps  Sta  t eient  s for  ENTITIES 

Tha  SYN0NYWS  , nr  FC^TPTTON,  SP’S'-MEKC,  KEYWORDS,  ATTRIBUTES, 
A?***"-,  SECURITY,  eU"RCE  an*  TPAC'-KEY  statements  may  be  use<1  in 
•■his  Section.  f'°s,;ri  pMon  an.1  syntax  of  these  statements  are 
niv^n  in  section  ?.?. 
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1 , 7 8TT  r^c*-.  iop 


i r”’T  ir.  i collection  of  or » or  ifor" 
con*  ajn  or  carry  da  Hi  va  ! m n , A SET 
of  r~»IT ITT CF,  TNP'JT'',  or  nq“? UTS,  but 
obi. ’of  * voa:;.  ""  l' a *"  is,  a Si'7’  canrot 
o'rrn’7'7. 


ocurroncos  of  obgegts  that 
may  represent  a collection 
not  a combination  of  these 
consis*-  of  both  INPUTS  and 


(list  of  set  names) 

vh=»re  E v "T'"Te g may  be  bought  of  as  logical  records,  a S’!?  may 
bo  thought  of  as  a logical  file.  Tn  any  case,  a SET  should  be 
used  according  to  fhc  algebraic  sense  of  the  word  "set." 

1.7.1  Ii.Y5l2IlzZi.21i  2*atement £ for  .SETS 

"hfl  ?ESrOMST  3 L7"-  lb”"  \ FAC 77  statement  soecifi^s  those  INTERFACES 
Hat  have  Ha  responsibility  >f  maintaining  the  information  in 
the  3F~. 

BP'7°H!ri  f '■>  T!^r  rpicf  jo-q'-o 

(list  of  interface  names) 

"vuv  crT  should  have  at  least  cr.e  responsible  INTERFACE. 


1 . 7 . ? Tv  stem  - structure  statements  for  SE"~S 

""he  srns^o  and  goner"-  abatements  specify  the  manner  in  which  a 
particular  is  r^la^ed  (in  the  algebraic  sense,  again)  to 

ot!i‘>r  sr-g  in  »•*  i target  system. 

A T can  h»  a c'’7  T of  a larqer  (or  euuivalent  size)  SET: 

rtpStn  (CS"1)  . 

(1  1st  of  so*-  names) 

A 3rT  can  also  have  a number  of  3UFSETS: 

oTtiarr-Tc  ('3TF) 

Mist  of  set  names) 

For  oxampl’,  a la4-'  base  may  he  defined  to  describe  all  the 
information  maintained  by  the  tarqet.  system.  The  data  base  may 
b-»  leMned  t0  po  a SET.  'tmaller  collections  of  data  in  the  data 
has"  snob  as  files,  e tc,r  would  then  be  defined  as  SUBSETS  of 
t h o da»a  ba  ; e . 
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The  s»]Bci?<r'-T  {jq-CFITF TA  statement  specifies  what  data  determines 
how  a SET  is  to  h“  subsetted. 

? U 3 S F T "'  ? II  G“  C ~ tT  E 7 7 A (SSCA) ; 

(list  of  suhsettinq-criter ion , 

“dement,  and  qroup  names) 

T f a 3F"‘  has  SUP 3*TS  , its  SUBSETTI  NfJ-CF  ITEBI  A should  be  defined 
also . 


3 . 7 . 1 Da  ta- Structure  Statements  for  SETS 

The  C?NSISTS  s*-a  teup  n t specifies  the  data  contained  in  the  SET 
and,  optionally,  the  number  of  occurrences  of  this  data  in  the 
SET. 

CON  STS"T  (CSTSI  ; 

(list  of  entity,  inout  or 
output  names,  optionally 
preceded  by  system- 
nara  meters) 

Every  SET  should  CONSIST  of  at  least  one  ENTITY,  INPUT,  or 
OUTPUT. 

,‘7>a  9a  t a- Deri  vat i or.  Eta  temgn  t s f cr  SETS 

The  U SrD  statement  specifies  those  FFOCESSES  which  use  the 
information  available  in  the  SET. 

i!5jn  _ _ _ • 

(list  of  process  names) 

This  implies  kM  t some  data  within  the  SET  is  being  USED. 

"’o  specify  the  manner  in  which  the  SET  is  USED  more  precisely, 
the  PET  I V"  or  'tPDAT.r  clause  may  he  in  conjunction  with  the  USED 
stat  eip^o  t . 

'i^n  ft 

(list  of  process  names) 

”0  DEFIV*  ( D“  V)  ; 

(list  of  eleraant,  qroup,  entity, 
set  and  output  names) 

or  UOFU  by  a ?ncrSS  to  UPDATE  data: 

us^p  ny 

M 1st  of  process  names) 


■mo  npr^To  r.?-) 
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(list  of  element,  group,  entity, 
and  set  names) 

""h  a st.at.“m»nt  specifies  those  PFOCESSES  which  derived 

som-1  information  presented  in  the  SrT. 

pprjvfn  jrpy  n)  - - _ — • 

(list  of  process  names) 

"'his  s4-  a t em«n  t implies  tha*  at  least  one  piece  of  lata  (ENTITY 
or  ' . UTPHT)  in  the  is  D~P  TVFD , To  specify  the  manner  in 

which  t hr  l*!TT"Y  or  nirpr’  is  derived  more  precisely,  the  fJSING, 
PEr>r  NOTNC  o\ , an  i pop  EACH  clauses  may  be  used  in  conjunction 
with  the  statement, 

pv  ( PPVP) 

(list  of  nrocess  names) 

’VO-..--*-.  - — •»  - . 

(list  of  elfm°nf , group,  entity, 

'o*  and  input  names) 


DFPEVDING  0 N 

(list  of  eltment,  condition  names) 

FOP  EACH 

(list  of  entity,  input,  output,  group, 
element,  c=»t-namc) 

The  HFPATEl)  s^atpwant  specifies  these  PROCESSES  that  may  modify 
information  in  the 

riPDATFp  (UPnP)  ; 

flist  of  process  nameS) 

"his  statement  imnlies  that  at  least  one  piece  of  lata  (FNTTTY) 
in  the  sr-  is  unnA"rP. 

~o  specify  mcr-’  precisely  the  manner  in  which  the  SET  is 
updated,  the  mr,,  r SPENDING  on,  and  EOF  EACH  clauses  may  be 
used  in  coniunetion  «ifh  the  UPCATFD  statement. 

r?p D*  "FT;  PY  (Oppo)  _ _ 

(list  of  nrocess  names) 


(list  of  element, groun,  entity, 
set  or  input  names) 


prpT.jpxpg  o»j 


(list  of  element,  condition  names) 


FOP  v AC H 


Hist  of  entity,  input,  output,  group, 
PA’*  I "f*P  pFQff  rp  KM  ENTS  LANGUAGE  KANUAL 


'Tfl  BO/MULTTCS/UPL  USFP'S  MANUAL 


1 50 


element,  set-naire) 

"v«ry  SFT  defined  should  be  ngED,  DEEIVFD  or  UPDATED  by  at  least 
or>t»  PrTCF5c'. 


D5T'TVATIOM  statement  should  he  used  to  specify  the  rules  for 
deriving  occ  u rrr  sees  o * data  in  the  SE'r.  Since  there  are  many 
diffor^n*  wavs  in  which  this  data  may  be  derived,  this 
information  is  presented  via  a comment  entry.  The  type  of 
information  specified  in  this  statemnt  might  he  what  value  a 
Darticular  TLFB^nt  ir.  an  ENTITY  must  have  to  be  entered  into  a 
CT!'T , etc. 

u vt»  I V a TT  0*1  (bn  V*’  ) ; 

(comment  entry) 

rvorv  ~v'"  should  have  DFFIVA  TIOV  specified. 

'"ho  CLAES I7i c A “ I 0 v of  a SEm  may  be  specified  with  the 
CLASSIFICATION  state  man t: 

CLASSIFICATION ; 

CM. s+  of  classification  names, 

*Mch  optionally  followed  bv 
a level  number) 

hv  nrocFSS^S  otr  pnncFSFOP?  that,  use  the  S^T  must  have  5 ECURITY- 
ACCF ss-cinups  *hat  match  the  classification  of  the  SFT. 


5 . 7 . c system- sire  Statements  for  SETS 

t h e c.  PI  NAT.  TTY  statement  specifies  the  maximum  number  of 
occurrences  of  da'-a  obiects  in  the  SE1"  at  any  one  time. 

CARDINALITY  (CAPO)  ; 

(system  parameter) 

Fverv  SFT  shoul  d have  a CA  FD IN  ALITY . 


I.7.  6 Dynamic  s Statements  for  SETS 

The  vo!A  TILITy-SEI  and  VOLATILTTY-MFMREP  statements  specify  how 
a rFT  changes  over  time.  Since  there  are  many  different  ways  in 
which  a SET  be  charged,  this  information  is  presented  via  a 

oommert.  entry. 

The  vci  AITLITy-s  ft  statement  specifies  the  manner  in  which  the 
entire  set  changes  over  time.  The  type  of  information  specified 
in  this  statement  might  be  the  number  of  times  members  are  added 
to  the  SFT,  members  ate  updated,  etc. 
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VOLA  TILTTY-3F'P  (VOI.S); 


(comment,  entry) 

The  VOLA  TILI TY-M  rM,BEF  statement  specifies  how  the  members  of  the 
s*T  change  iv«r  time.  The  type  of  information  specified  in  this 
statement  might  he  * he  number  of  additions  to  the  SET  of  a 
particular  ENTITY  type,  the  number  deleted,  etc. 

VOLATILITY- ME  MU  (VOLM)  ; 


(comment  entry) 

Fv»rv  SET  should  have  VOLATILITY-SET  and  VOLATILITY-MEMBER 
statements  uiven  for  them. 


3 . 7 . v "rogect^Ma nage ment  Statements  for  SETS 

The  PFS  PONS  I PL.T-  PROBLEM -DEFINE?  statement,  may  be  used  in  this 
Section,  oe scri ot.ion  and  syntax  of  this  statement  are  given  in 
section  3.2. 


? . 7 . B System- Properties  Statements  f or  SETS 

The  SYNONYMS,  PE SCSI  riTOK , SEE-MEMO,  KEYWORDS,  ATTRIBUTES, 
ASSERT,  .SECURITY,  SO  n pcE  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
giver  jn  section  ',.2. 
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"’.3  RELATION  •'ection 

A PT  T A"1!  Of!  is  a name  d loaicnl  connection  between  two  ENTITIES 
n^rceivel  by  th-»  Problem  Refiner.  Any  (JRL  name  may  be  used;  the 
most  meaninaful  name  to  the  Problem  Definer  should  be  one  which 
denotes  the  connected  FNTITI’:’S, 

^U"ION ; 

(list  of  relation  names) 

Tf  a system  w0!-'  being  described  that  consisted  of  EMTITTFS  for 
women  an  1 :rN'Tr~I'’c  tor  men,  a possible  PFLA"ION  to  connect  these 
F.NTT TISS  nigh*  b?  "soouse." 

3.  s.  1 Data-pt  closure  statements  for  RELATION  5 

a or"VT>|  st a tomf-r.t  specifies  the  names  of  the  ENTITIES  that  the 
"ELATION  connects  and  the  direction  of  the  connection.  The 
direction  is  leto’-mined  by  the  crdec  of  the  ENTITY  names  in  the 
statement:  from  the  left  (first)  ENTITY  to  the  right  (second) 
rri’?,  The  tirst  ENTITY  can  be  considered  the  owner  of  the 
PTI.A','TON  and  the  recond  ENTITY  the  member  of  the  RELATION. 

R^T  W FEN 

(r3  me  of  entity) 

ANT ; 

(na  me  of  en  tit  y) 

"xamole;  Re""HET:N  PEP  A Rtfl^NT-RFCOPD  AND  UOUPL Y-ENPLOY TE-P ECORD : 

■"he  RELATION  , D?  RAPT  EMT-  ""O'*  HO U PLY- EM.PLO  YEE , denotes  a logical 
correction  between  tVo  ENTITIES,  DEPARTS ENT- RECORD  and 
nogPLY-EKPLOY  PE-  rTC°  PC.  The  direction  is  from  PE  PAR  TEEN  T-  RECORD 
to  fforjFi  Y-EN PLOY RECORD  . •’’he  DFFAFTEEN"-PECOFD  is  the  owner 
and  HOM  Pi  Y- r N PL''  Y "ON  f— P ECOPD  the  member  of  the  RELATION. 

Only  one  B71,,i,r,l  statement  can  ^e  given  tor  a particular 
D "LA  TIOP  , but  each  PFLA'T’TON  should  have  a R^TWFEN  statement 
given  for  it. 

"he  ASSOCI ATED-D  A'"®  statement  specifies  those  GROUPS  and 
rT,«,MFN"R  that  contain  information  specifically  about,  the 
"SLA TION  and  are  rot  necessarily  CONTAINED  in  either  ENTITY. 

ASSOCIATED*' DA  "A  T.T _ ; 

(list  of  element  and  grouo  names) 
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d.U.2  Da^a-Oeriv anion  f^atemeuts  for  RELATIONS 

A 'htntajkjR"1  ny  Sfa  t e mont  designates  those  PROCESSES  which  add, 
d(;lptn  or  modify  thr?  connection  occurrences  between  the  ENTITIES 
that  arc  connected  hv  *his  °ST. ATION. 

*H!V  TWINED  D Y ; 

(list  of  process  names) 

”o  specify  more  precisely  the  manner  in  which  the  RELATION  is 
maintained,  ♦he  DEPENDING  ON  and  ECR  EACH  clauses  may  be  used  in 
conjunction  wi<-h  the  MAINTAINED  BY  statement. 

M AIN  TAIN  ED  BY 

(list  of  process  names) 

NOIf’O  0M 

(list  of  element,  condition  names) 

’’OP  EACH ; 

(list  of  entity,  input,  output,  group, 
element,  set-names) 

A RELATION  can  be  MAINTAINED  by  several  PROCESSES,  and  every 
PWLSTI0N  should  b°  MAINTAINED  by  at  least  one  PROCESS. 

Tha  DERIVATION  statement,  should  be  used  to  specify  the  rules  for 
deriving  occurrences  of  the  RELATION  between  the  ENTITIES  . 

Since  there  are  many  different  ways  in  which  this  data  may  be 
derived,  this  information  is  presented  via  a comment  entry.  The 
type  of  information  specified  in  this  statement  might  be  what 
are  the  restrictions  in  relating  two  ENTITIES,  which  PROCESSES 
mav  forma  the  relation,  otc. 

DERIVATION  (D^VN)  ; 


(comment  entry) 


Every  I ATT  ON  should  have  a DERIVATION  specified. 


1 . a . ^ System- Rive  Sta tement s for  PELATIONS 

A COCNECTIVTtv  statement  specifies  the  number  of  ENTITY 
occurrences  of  the  first  (right)  ENTITY  that  are  related  to  a 
number  of  ENT I" Y occurrences  of  the  second  (left)  ENTITY. 

CONNECTIVITY  IS  

(syst  em- parameter) 


tc 

(system- para  me  ter) 
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If  a particular  ENTITY  occurrence  may  be  related  to  only  one 
other  TNTTTY  occurrence,  the  CONNECTIVITY  is  1 to  1.  If  a 
particular  ENTITY  occurrence  may  be  related  to  one  or  more 
**NTI'TY  occurrences  ♦ he  CONNECTIVITY  is  one  to  many.  The  right 
and  left  SYSTM-  PA°A  "STEF*?  in  the  CONNECTIVITY  are  intended  to 
correspond  to  ‘ho  riqht  and  left  ENTITIES  given  in  the  BETWEEN 
statement . 

f»>r7  PFT,A’PTor  should  have  one,  and  only  one,  CONNECTIVITY. 

* CARDINA!ttY  specifies  the  maximum  number  of 

connect! cn  occurrences  for  this  RFLATION  . 

CAPPTNAI  TmY  IS ; 

(s vs t em- parameter) 

^ve ry  r'FLA’rIO'J  should  have  one,  and  only  one,  CARDINALITY. 

3.3.4  Pr odect-*a nace men*-  statements  for  RELATIONS 

'"he  RESPONSIBLE- ncOB I Er- DEFINE F s+atement  mav  be  used  in  this 
Section.  Description  and  syntax  of  this  statemnt  is  given  in 
sectior  3.?. 


3.3.  * System  - ?i  oner  ties  Ftat  omen*  s for  F ELAT  IONS 

"he  *»YNO  N YTR , DC  SCI t PTTON,  BEE- MSEC,  KEYWORDS,  ATTRIBUTES, 
asSE®",  S ECU  "TTY,  **D  T?  BCE  and  IF  ACE-KEY  statements  may  be  used  in 
♦■his  section.  Description  ari  syntax  of  these  statements  are 
given  in  section 


R.°.f  ZZ-lilElf  2 f 3 ii?J!rl£22  RELATION  Section 
°Ft7  Tier  dona  rtm  »r.t-  t o-hourly-empl  oyee; 

ARSOciA^Er- pa^r  is  last-department-change; 
r'KIW'-  IP  fr  eouency- of-use ; high; 

T»ETW”’,v  *enar3  men*-recor  1 ANT  hourl y-em ployee-recor d: 
CAFOTN* T T""Y  T<J  r,umher-of-hour  ly-employees; 

CC N NETT I VTT Y IF  1 TO  ma x-departraant-emplovenent ; 

C^p  ZVK~"  row  . 

nev- emni oyep- processing  adds  connections  while 
term  i nat  inti- employee-processing  deletes  connections; 
rr’cCRIPTTCN  ; 

this  relation  connects  an  hourly-employee-record  for 
each  ennloyeo  in  a department  to  the  department- record 
for  that  department ; 
x- y wmp  d -*n  arf  men*--i  nf  o rma  t.ion  ; 

K A T N'-a I v vn  uy  n ew-employee- processing  AND 
‘»r"i  j ".a*-  ing-eirnloye^-processinq  /*  U3IN0 
^i»narf»on‘  A'U)  employee-identification-number  */; 
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p-SPONSTBLE-P?OBLFM- DEFINES  -john-nroctor; 

SECURITY  denar*  ment- h<?a ds , department-secretaries; 
SE^-MET)  comnan  v-or  g an  izat  ion- chart ; 

SOURCE  on  pi  ovee-a  p plica  tion-f  orm , 

employ ee-termi nation- form, 
de  oar t men t-em ploy ee- list; 

SYNONYM  dopt-to-emp,  d-e; 
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l.o  npppp  are  f££i±2JL2 

Vi  r LFirv”  is  the  Invent  level  data  object  that  can  he  defined 
*■  o Inscribe  d >M  . nocause  of  this  property,  an  ELEMENT  has  one 
m *or>  possible  la*  a values  associate!  with  it,  whether  it  he 
alphabetic,  ivi">'ric  or  otherwise.  In  many  instances  an  ELEMENT 
mav  he  thouoht  of  syronymouslv  with  "field”  or  "item." 

FI.TM?V,T  (TIE)  ; 

(list  of  element  names) 

> CROUP  repress*.*;  a collection  of  ELEMENTS  and/or  GROUPS.  The 
us®  of  GROUPS  is  definitional  which  means  that  referencing  a 
particular  orour  bv  its  name  is  equi  valent  to  referencing  the 
individual  FT.^FF  which  the  GROUP  consists  of. 

GROUP  (C,OJ  ; 

(M  Ft  of  qroup  names) 

GROUPS  can  b«  broken  down  info  smaller  GROUPS  and  ELEMENTS , but 
rLcvENTS  cannot  •,«  subdivided.  EII'1ENTS  may  ta|<(-,  on  values 
where  c>POUPr  -"av  rot.  The  value  of  a GROUP  is  defined  to  be 
equivalent  to  the  individual  values  of  the  ELEMENTS  within  the 
group. 


t a- Structure  Statements  for  GROUPS  and  ELEMENTS 

"he  crv”  AINEP  sta^nert  is  used  to  relate  the  data  structure 
relationships  of  GFOUPS  and  ELEMENTS  to  ENTITIES  , INPUTS  and 
oM-piiT.,.  pata  is  most  often  thought  to  be  part  of  some  larqe 
uni*-  of  data  such  as  a logical  record,  input  form,  or  on  tout 
report,  which  can  be  represented  by  *he  ENTITY,  INPT7T  and 
OUTPUT,  respectively. 

rov'tBTfjrp  (cv^n)  ; 

(list  of  group,  entity, 
input  and  output  names) 

quogns  and  TLF^EHTR  may  bp  defined  to  be  CONTAINED  in  some 
laraer  gpoud  . 

Th  * COMET  STS  s^atewent  is  used  t.o  specify  those  lower  lavel 
groups  anq  FLFMDN7F  a GROUP  may  consist  of.  By  definition  of 
"PLESFR-, * an  PT.  EM  FN"  cannot  CONSIST  of  anv  other  data  objects, 
"h*  CCM  CT  ITS  statement  only  specifies  the  data  in  the  GROUP  and 
implies  nothing  about  its  format. 

CONSISTS  (CSTS) ; 

(list  of  qroun  and  elemon*  names,  optionally 
preceded  by  system  parameters) 

* coi»fle*-e  problem  statement  should  have  all  GROUPS  broken  down 
fo  smaller  GROPES  and/or  ELEMENTS. 
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The  iSSOCIA”  staremen*  specifies  those  RELATIONS  that  the 
GROUPS  or  EL  F MEN are  associated  with.  This  implies  that  the 
information  in  the  GROUP  or  ELEMENT  is  in  neither  of  the 
ENTITIES  the.  ^ELATION  is  BETWEEN. 

ASSOCIATED  ( A ~00) ; 

(list  of  relation  names) 

""hQ  IDENTIFIES  statement  specifier  those  ENTITIES  for  which  the 
GPQU?  or  ELEMEN"’  is  used  as  an  identification  key.  This  implies 
tha*  the  possible  values  of  the  GPCUP  or  ELEMENT  are  all  unique, 
'or  example,  the  ELEMENT*  which  represents  social  security  number 
in  an  employee  record  might  be  used  as  an  identifier. 

TDEN  T7pT  EC  (IDS)  ; 

(list  of  entity  names) 

a group  or  ELEMENT  may  identify  any  number  of  ENTITIES. 


7 . n . 1 Svst am-struct  ure  Statements  for  GROUPS  and  ELEMENTS 

The  srPEET^N  G-Cp  Iwr  TON  statement  specifies  those  SETS  which  are 
outsorted  hisoi’  on  the  data  values  in  the  GROUP  or  ELEMENT. 

SmSET^ING-GFITEr  ION  (SSCN) ; 

(list  of  set  names) 


3.  R.l  Pa  »a-Perivation  Statements  for  GROUPS  and  ELEMENTS 

The  USED  statement  specifies  those  PROCESSES  which  use  the 
information  in  v . h«»  0 ? OUP  or  ELEMENT , 

USED ; 

(list  of  process  names) 

This  statement,  implies  (in  the  case  of  a GROUP)  that  at  least 
one  piece  of  data  in  the  GROUP  is  beina  USED. 

To  specify  the  manner  in  which  the  GROUP  is  USED  more  precisely, 
the  D F r T V E or  UPDATE  clause  may  be  used  in  conjunction  with  the 
USED  statement. 


USED  BY 


(list  of  process  names) 


*0  DEF IVr  (DnW)  

(list  of  element,  group,  entity, 
set  and  output  names) 
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or  U S r D by  a PROCESS  bo  UPDATE  da*a: 

used  PY 

(list  of  process  names) 


TO  UPDATE  (UPD)  ; 

(list  of  elemen*,  group,  entity, 
and  set  names) 

"h » DECI VED  statement  specifies  those  PROCESSES  that  derived 
some  information  oresented  in  the  GFOUP  or  ELEMENT. 

PEEVED  (DRVP) ; 

(list  of  process  names) 

’’’his  statement  implies  (in  the  case  of  a GROUP)  that  at  least 
one  piece  of  data  (GROUP  or  ELEMENT)  in  the  GROUP  is  DERIVED, 
'"o  specify  more  precisely  the  manner  in  which  *he  GROUP  or 
ELEMENT  is  derived,  the  USING,  DEPENDING  ON,  and  FOR  EACH 
clauses  may  be  used  in  conjunction  with  the  DERIVED  statement. 

DERIVED  PY  ( DRVD)  

(lisb  of  process  names) 


MR  TJJG ; 

(1  ist  of  element,  group,  entity, 
sen  and  input  names) 

DEFENDING  ON 

(list  of  element,  condition  names) 


FO?  EACH ; 

(list  of  entity,  input,  output,  group, 
element,  set-names) 

"he  UPDATED  statement  specifies  those  PROCESSES  that  modify  some 
information  presented  in  the  GROUP  or  ELEMENT. 

UPDATFD  (HPD  D) ; 

(list  of  process  names) 

This  statement  implies  (in  the  case  of  a GROUP)  that  at  least 
one  niece  of  data  (GFOUP  or  ELEMENT)  in  the  GROUP  is  UPDATED. 

To  specify  more  precisely  the  manner  in  which  the  GROUP  or 
ELEMENT  is  updated,  He  USING,  DEPENDING  ON,  and  FOR  EACH 
clauses  mav  he  used  in  conjunction  with  the  UPDATED  statement. 

mpdATFD  ry  (M?PD)  

(list  of  process  names) 

USING ; 

(list  of  element,  group,  entity, 
set  or  input  names) 
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DEPENDING  ON 

(list  of  element,  condition  names) 


fq  9 rA°T1  ; 

(list  of  entity,  input,  output,  group, 
element,  set-names) 

Every  GROUP  and  ELEK  F NT  defined  should  he  USED,  DERIVED  or 
UPDATED  by  at  least  one  PROCESS. 

The  CL  AS  CI  FT  C AT  ON  o f a GROUP  or  ELEMENT  may  be  specified  with 
the  CL.aseitc  a~ton  statement: 

ClASSIFTCATON ; 

(list  of  classification  names,  each 
optionally  followed  by  a level  number) 

Anv  P nrc  r3  3 EE  or  PRO  C ESSO’5'7  that  usa  the  GROUP  or  ELEMENT  must 
have  SEC n?ITY- * CCE3E- RIGHTS  that  match  the  classification  of  the 
GROUP  or  ELEMENT  . 


?.9.U  ?y  stem-  Si7  e Statements  for  5IFNENT5 

,T,h e VALUE  statement  is  used  to  define  numeric  values  an  ELEMENT 
may  have.  A (Ton P cannot,  have  a VALUE  directly  associated  with 
it.  Th°  VALUE  statement  may  only  specify  numeric  values  and 
does  nov  imply  anything  about  st.oraqe  format,  etc.  The 
' "TR  IRUT3  an!  DESEFTPTON  statement  should  be  used  to  present 
this  type  of  intori„ation  as  well  as  to  specify  character  values. 

VALUE  ( V * L)  ; 

(inteaer  value) 

Only  rositivo  values  may  be  specified.  Decimal  numbers, 

n^iat.iv-'  numbers,  etc.  are  not  acceptable. 

A range  3f  values  ray  also  be  specified. 

VALU  FS  ( VAL)  ..THRU ; 

(minimum  value)  (maximum  value) 

Again,  t he  values  must  hr  positive  integers.  POSIMP  and  NEGINF 
mav  be  iis-H  to  ronreser*  positive  ani  negative  infinity, 
r°snecti vel v . 

orlv  one  VALU7  statement,  of  either  of  the  forms,  may  ba  qiven 
to  '’eseribe  a particular  FLEEENT. 


PAP 
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■* . 9 . r>  Prolog  t.-Ma  nane  went.  Sta  toaents  for  GROUPS  and  ELEME  NTS 

The  RESPONSIBLE-  PFOBL EM-DEETNER  statement  nay  bo  used  in  Phis 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.2. 


3.9.6  By  stem-  Properties  Statements  for  G ROUPS  and  ELEMENTS 

Th®  SYNONYMS,  PSSCRT pTION , SES-KEKO,  KEYWORDS,  ATTRIBUTE, 

Abbfpt,  SECURITY,  SOURCE  and  TP  ACE-KEY  statements  nay  be  used  in 
this  Section.  nescriptior.  and  syntax  of  these  statements  are 
qiv»n  i**  section  3.2. 
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3.10  PROCESS  t ior 

Thp  FcncFss  used  *o  define  t he  function,  or  functions  of  the 
*aruet  system.  A * the  highest  level,  the  function  of  the  target 
system  mav  he  defined  as  a single  PROCESS . "his  PROCESS,  could 
in  turn,  b-'  broken  down  into  more  detailed  PROCESSES.  It  is  the 
task  of  the  PROCESS  to  reference  and  manipulate  data  in  the 
target.  svs*em. 

PROCESS  (PPC1 ; 

(list  of  process  names) 


R.lh.l  s ystem-rl aw  S tatement s for  PROCESSES 


Tho  ^EC^ IVES  statement  is  used  to  specify  that  the  PROCESS 
accents  information  ("SPOTS)  from  outside  the  target  system. 


RECEIVES  (PCVS1 


(list  of  input  names) 


This  statement  on.lv  specifies  that  the  IN  POTS  are  accepted  by 
kh-1  PFOCESS  and  doe-;  no*  imply  tha*  the  information  in  the 
INPUTS  are  USED  or  how  it  is  USED  by  the  PF0C2SS. 

"o  specify  mor-*  precisely  the  manner  in  which  the  INPUTS  are 
received,  the  depending  OS  and  FOR  EACH  clauses  may  be  used  in 
conjunction  with  the  RECEIVrS  statement. 

R EC v I V*1?  _ _ 

(list  of  input  names) 


DEPENDING  OS  

(list  of  element,  condition  names) 


PO-  EACH ; 

(list  of  entity,  input,  output,  group, 
element,  set-names) 

The  GENERATES  statement  is  used  to  specify  that  the  PROCESS 
produces  information  (OUTPUTS)  for  use  outside  the  target 
syst  em. 

GENERATES  (GFSS) ; 

(list  of  output  names) 

This  statement  only  specifies  that  the  OUTPUTS  are  distributed 
by  *he  PROCESS,  and  does  not  imply  that  the  information  in  the 
OUTPUTS  is  DFRIVED  by  the  PPOCESS. 

To  specify  more  precisely  the  manner  in  which  the  OUTPUTS  are 
generated,  th°  D EPFN  DING  ON  and  FOR  EACH  clauses  may  be  used  in 
conjunction  with  *h»  GENERATES  statement. 


PA  0,r  T USER  F EQU IR  EMENTS  LANGUAGE  MANUAL 


■M  1 P'V'1ULTTCS/UPL  USER*  S •'ANHAI. 


162 


^rv-pg-T-rc  _ 

(list  of  outmit  names) 

n? PENDING  DM 

(list  of  element,  condition  names) 

"OR  EACH ; 

(list  of  entity,  input,  output,  group, 

°lem«nt,  set-  names) 

"’hese  statements  imply  that  some  physical  processing  or 
tran slat  ion  ihv  h«  necessary.  The  FFCEIVFS  statement  means  that 
•■he  physical  meats  containing  data  must  be  accommodated, 
similarly,  the  G "KrT5  A T^S  statement  means  that  data  must  be 
recorded  in  wha'evpr  medium  has  been  chosen. 


3.1  '.2  S v stem-  St  r u re  Sta  temen  ts  for  PROCESSES 

A process  mav  b^>  part  of  one,  and  only  one,  larqer  PROCESS,  and 
if  mav  have  anv  number  of  subparts  that  are  also  PROCESSES. 

PAC  m 

(process  n.am?) 

SMD°  AD'rS  (SHD  s) ; 

(list,  of  process  names) 

r’hese  statements  permit  organization  functions  and  programming 
structures  to  be  defined  for  the  problem  statement. 

""he  Dill  TZED  and  UTILIZES  statements  are  used  to  specify  that  a 
PPnCEc?  represents  a function  used  hy  several  other  PROCESSES. 
Definition  of  n'”!T,T7F  D implies  that  the  PROCESS  is  common  to 
more  than  one  other  PROCESS.  If  not,  the  PROCESS  should  be 
define  1 as  a '•uppAR"' . 

UTILIZED  (FJTLO)  ; 

(list  of  process  names) 

iriLI?EE  (l?"I«)  ; 

(list  of  process  names) 

* given  hroee?'7  mav  have  any  number  of  CUBPAFTS  and  UTILIZE  any 
number  of  other  PROCESSES.  A PROCESS  may  be  a SUBPA?”’  of  only 
on°  ether  pROT^si,  but  be  riTTLTZtjD  by  anv  number  of  PROCESSES. 

mo  specify  nor-'  precisely  the  manner  in  which  the  PROCESSES  are 
utilized,  the  UPENDING  os  and  FOP  EACH  clauses  may  be  used  in 
roniunction  with  ,,'rIlTZFS  statement, 

'TTT T TEES’ 

(list  of  process  names) 
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DEPENDING  ON 

(list  of  elpment,  condition  names) 

PO^  EACH ; 

(list  of  entity,  input,  output,  group, 
element,  set-names) 

3. 1C.  3 Data-  Peri  vat  i on  f ta  te  menj^s  for  PROCESSES 

The  OSES  statement  specifies  those  SETS,  INPUTS,  ENTITIES, 

OP  OH  PS  and  F LEE’7  NTS  from  which  some  information  is  taken  and 
used  hv  the  PROCESS  to  perform  its  designated  function. 

USES 

(list  of  set,  input,  entity,  qroup  and  element  names) 

Tn  the  case  wher°  SET,  INPOT,  ENTITY  or  GEOnp  names  are  given, 
this  statement  implies  that  at  least  one  ELEMENT  within  these 
are  UST'D  by  the  PPOCESS. 

To  specify  the  marner  in  which  the  PFOCESS  OSES  the  data  more 
precisely,  the  DERIVE  or  UPDATE  clause  may  be  used  in 
coniunction  with  *he  OSES  statement. 

OS  ES 

(list  of  set,  input,  entity,  group  and  element  names) 


’”0  DEPIVE 

(list  of  set,  output,  entity, 
group  and  element  names) 


OSES 

(lis4-  of  set,  input,  entity,  group  and  element  names) 

TO  OPnA^E ; 

(list  of  set,  entity, 
group  and  element  names) 

~he  DvpjvES  statement  specifies  those  SETS,  OOTPUTS,  ENTITIES, 
GROUPS  and  ELEESN"T  for  which  seme  information  is  derived  by  the 
PFOCESS  *o  perform  its  designated  function. 

DERIVES  (0”VS) ; 

(list  of  set,  output,  entity, 
group  and  element  names) 

Tn  the  case  where  SET,  OUTPUT,  ENTITY  and  GROUP  names  are  qiven, 
this  s^atnnen*-  implies  that  at  least  one  ELEMENT  within  these 
are  DERIVED  bv  the>  PFOCESS. 

”o  specify  the  manner  in  which  the  PFOCESS  DERIVES  the  data  more 
precisely,  the  OSTNG,  DEPENDING  ON  and  EOF  EACH  clauses  may  be 
usea  in  coniunction  with  the  DERIVES  statement. 
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OE«IVFS  (Dn  VF ) 

(list  of  set,  output,  entity, 
qroup  and  element  names) 

UP  I NO ; 

(list  of  set,  input,  entity, 
qrouo  and  element  names) 

OEPFNDINO  Of.' 

(list  of  element,  condition  names) 

PCP  FA  CP ; 

(list  of  entity,  input,  output,  qroup, 
element.,  set.- names) 

■'•ho  riPDAT”  stifon?r.  t specifies  those  SF.'"S,  ENTITIES,  GROUPS  and 
PT^ffFN^f  for  which  some  information  is  updated  bv  the  PROCESS  in 
performing  i *■  s designated  function. 

(JT>D  f TEC  (0nDc)  ; 

(list  of  set,  entity, 
qroup  and  “lament  names) 

In  *he  case  where  O^T,  ’’KTITY  and  GPOUP  names  are  qi ven,  this 
statement  implies  that  at  least  one  EI.FEFNT  within  these  are 
UPn&^IP  by  the  °?CCE  S S , 

T o specify  the  manner  in  which  the  PROCFSS  UPDATES  the  data  more 
precisely,  the  U STHG , DFPENPING  ON  and  FOF  EACH  clauses  may  be 
used  in  conjunct  ion  with  the  UPDATFS  statement, 

PPPATFS  (ipm?) 

(list  of  set,  entity, 
qroup  and  element  names) 

USING ; 

(list  of  set,  input,  entity, 
croup  and  element  names) 


0 ’’PENDING  ON  

(list  of  element1,  condition  names) 

POn  EACH ; 

(list  of  entity,  input,  output,  group, 
element,  set-names) 

^he  MAINTAINS  rtat^ment  specifies  those  RELATIONS  or 
SMBSETTINO-CFTTERIOV  which  are  maintained  by  the  PPOCFFS  . 
"aintenanc**  of  'STATIONS  normally  involves  addition  and  deletion 
of  connections  between  ENTITIES  whereas  maintenance  of 
SMB  SETTING- CRIDER  ton  deals  with  placement  of  ^NIITIES,  INPUTS 
and  OUTPUTS  in  proper  SETS  accordinq  to  the  values  of  the 
rEEMENTS  an * Gr OUPe  contained  within  t-hose  desiqnated  as 
SUBSSITING-OI 'TERION  names. 
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X A IN  "AT  N S (MTN^)  ; 

(list  of  relation  and 
subsetting  criterion  naraes) 

"o  soecifv  nor?'  precisely  the  manner  in  which  the  PROCESS 
maintairs  a ^ELATION  or  EURSETTING-CRI^PION , the  DEPENDING  ON 
and  EOF  EACH  clauses  may  be  used  in  coni  unction  with  the 
MAINTAINS  statement. 

M * IN  rrATN  S 

(list  of  relation  and  subset.^inq 
criterion  naraes) 


DEPUTING  on  

(list  of  element,  condition  names) 

POP  TAOF  _ ; 

flist  of  entitv,  input,  output,  group, 
oilmen*-,  set-names) 

rvrarv  ntnCESc  should  be  defined  to  interact  with  data  in  some 
manner  (oppiv'c,  u<?3E,  UPDATES  or  MAIN? A INS)  . 

"h*4  FPOCED'IPP  statement,  is  used  to  specify  an  algorithm  of  the 
function  oF  tha  n"°crss.  "he  PROCEDURE  statement  is  a comment 
entry  statement  thus  allowing  any  form  of  procedure 
specification  tG  given  such  as  decision  tables,  actual 
program  code,  narrative  format,  etc. 

PPOC E DUr  r (PPCPi  ; 


(comment  entry) 

"very  PPOC'O?  that  does  not  have  E UBPAFT E or  does  not  UTILIZE 
anv  other  PrOCT(;.Sr<:  should  have  a PPOCCDUFE  statement  that 
specifies,  ’n  sufficient  detail  for  implementation,  the  rules 
for  carrying  onf  its  function. 

"he  EECHpity-acCESS-F  IGHTS  of  a PFCCEES  may  he  specified  with 
the  srcUFTT?- ACC  EPS- FIGHTS  statement: 

ETCP,5T"Y-  ACC  v "E-  PIGM  TS  _ ; 

(list  of  classification  names, 
each  optionally  followed 
by  a level  number) 

■ vrrrft  *ha*  uses,  derives  or  undates  data  must  have 

’ * T"Y- A"~  r "?»  ■’IGH"  S that  match  the  classification  of  the 
* ♦*  * . 
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•"he  RA^P FNS  statement  is  used  to  specify  the  frequency  of  a 
PFOC"ES  in  a qiv time  interval. 

UAPPrNF  ("A  P)  TTME3-PFR  (TIMP)  ; 

(system  parameter)  (interval  name) 


HAPPENS  EV^PY 


(system- parameter)  (interval  name) 


HAPPENS  r MI”  HIM  ) AFTER ; 

(system  parameter)  (interval  name)  (Event) 

■’.IC.E  System -Dynamics  Statements  for  PROCESSES 

•"he  TRIGGERED,  "EEMINATED  and  I NTEFF  OPTED  statements  are  used  t.o 
specify  those  EVENTS,  INPUTS,  PROCESSES  and  CONDITIONS  that 
affect  the  initialization  of  processing,  or  the  halting  of 
processi ng. 

"’PlOGFpPp  BY  (’"ROD)  ; 

(list  of  event,  input  and/or  process  names) 

To  specify  more  precisely  the  manner  in  which  an  EVENT,  INPOT  or 
PROCESS  is  triggered,  the  DEPENDING  ON  and  FOR  EACH  clauses  may 
he  used  in  conlunction  with  the  TRIGGERED  BY  statement. 


TRIGGERED  BY 


DEFENDING  ON 


(list  of  event,  input  and/or  process  names) 


(list  of  element,  condition  names) 


FfiP  EACH 


(list  of  entity,  input,  output,  group, 
element,  set-names) 


TRIGGERED  WHEN  (TPGD) BECOMES  TRUE  (T); 

(condition  name) 

TRIGGEFFE  WHFN  (TFCD) BECOMES  FALSE  (F)  ; 

(condition  name) 

T2PM  IN ATED  BY  (T'RMD) ; 

(list  of  avent,  input  and/or  process  names) 

To  specify  more  precisely  the  manner  in  which  an  EVENT,  INPUT  or 
PROCESS  is  terminated,  the  DEPENDING  ON  and  FOR  EACH  clauses  may 
he  used  in  conlunction  with  the  TERMINATED  BY  statement. 


TERMINATED  by 


(list  of  event,  input  and/or  process  names) 
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DEn-rNDTNG  ON 


(list  of  element,  condition  names) 


FOP  EACH 


- T-MMMWt  • 


(list  of  entity,  input,  output,  group, 
element,  set-names) 

To  specify  more  precisely  the  manner  in  which  an  EVENT,  INPUT  or 
PROCESS  are  interrupted,  the  DEPENDING  ON  and  FOR  EACH 
statements  mav  be  used  in  conjunction  with  the  INTERRUPrED  BY 
statement. 


INTERRUPTED  BY 


DEPENDING  ON 


(list  of  event,  input  and/or  process  names) 


pot?  EACH 


(list  of  element,  condition  names) 


(list  of  entity,  input,  output,  group, 
element,  set-names) 


""  IP v I '!  A"-  ED  WHEN  (TRMP) BECOMES  r'R  HE  (T)  ; 

(condition  name) 

TERMINATED  WHEN  TEMP) BECOMES  FALSE  (F)  ; 

(condi  tion  name) 


TN  IF  F P (JP  ,TEP  BY  (TN^P) 


(list,  of  event,  input  and/or  process  names) 

prpp  ’r3p  WH"H  (T N m D) BECOMES  TRUE  (T)  ; 

(condition  name) 


INTERRUPTED  WHEN  JIV'D) 


BFCOM  ES  FALSE  (F)  ; 


(condition  name) 


hrocVSES  mav  also  TFIGGFP,  TERMINATE  and  INTEPFUPT  other 
PROCESSES. 

TRIGGERS  (TRGS) ; 

(list  of  process  names) 


TERMINATES  (TEVS) 


(lis*  of  process  names) 


IN”'*’  F PnpTS  (IN"G) ; 

(list  of  process  names) 
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PPOCESSFS  may  also  generate  EVENTS  and  set  values  of  CONDITIONS. 
An  r VFN"-  may  ve  generated  either  at  the  initiation  of  a PROCESS 
or  when  it  finishes. 

T*’CEP"TON-?A  US*S  (INCC) 

(list  of  event  names) 

ern v IKAmION-CA”SFS  ( TEP?)  

(list  of  event  names) 

NAK  - S mRUE  (?)  ; 

(list  of  condition  names) 

K AKrS FAL  SF  (F)  ; 

(list  of  condition  names) 

’’’he  T NCF  P^ID  S— 0 A USEC  , TFR  PIN  ATION-C  A USES  and  KAKFS  statements 
allow  the  use  o*  the  optional  clauses  DEPENDING  ON  and  FOR  FACH. 

A PROCESS  may  or  may  not  be  involved  in  any  system  dynamics 
rela  t ion  ships . 

3.1r.*  System -Archi t ecture  statements  for  pr°CE5SES 

Tha  PE* FORMED  statement  specifies  the  physical  PROCESSOR  (e.g., 
hardware  or  orm  nivat  ional  unit)  which  performs  the  functions 
described  by  the  PROCESS. 

PERFC'FFO  (°I  KP)  ; 

(name  of  processor) 

Tv°ry  PROCESS  should  be  PERFORMED  by  some  PROCESSOR. 

"he  PESOnpCF- USAGE  statement  indicates  resource  consumption 
associated  with  the  PROCESS. 

B5S0 UPC^-US AG”  (prt)  _ FOP  ; 

(system  parameter)  (name  of  resource- 

usage- para  meter 

3.1'"'.*7  Pro^ect^y anagement  stat omerts  for  PROCESSES 

'"he  P£SPONST  P L*  - PF^BL  EV-DEF”N  EP  statement  may  he  used  in  this 
Section.  r'°scrip*'ion  and  syntax  of  this  statement,  are  given  in 
section  3.2. 


P>” 
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vf  ^ c'C/MnL”"T cis/upl  ns^p'S  vanhal 


5 . 1 ? . 0 f-y.i»em 
",h«  ? Y\’  'NY‘1S  , 

srcv-jT^  S^rnr 

this  ?°ction . 
l i v p n in  sec *■ 


Z-L22ZI 2l  3 t.a tem en_t s for  PROCESSES 

dje  m p^ow,  keywords,  attribute  , 

T"Y , ''"Hiper  and  TRA<~F-KFY  statements  may  be  used 
Ascription  an  1 syntax  of  these  statements  are 
ion  ?.  ">  . 
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"M*  I'7E’VjI.  Action 

an  I 'Trrp  VAL  is  msH  to  define  a sequent  of  time.  A week  or  day 
ar**  simnl^  examples  of  INTERVALS. 


Txi-pr-jyj  j (I” 


(list  of  interval  names) 


It  is  important  to  note  that  unless  defined  as  a SYNONYM,  WEEKS 
is  not  t>e  niup  as  '•'FYK.  In  most  cases,  it  is  desirable  that 
both  ramns  renres°nt  th°  sane  interval. 


3 . 1 1 . 1 S ysteir-St  ruct  »re  statements  for  I M TF?  VMS 

mh  a CONS  !F~s  statement  specifies  the  smaller  INTERVALS  that  the 
INTERVAL  can  b°  broken  down  to. 

»y  c ▼ cr  e (pc  T ^ ) • 

(list  of  interval  names,  each 
optionally  preceded  by 
a svst°m  parameter) 

c YS'T'Fd-P  A PA.'T'TF’5  should  be  specified  to  mate  the 
relationship  hatween  intervals  meaningful.  It  makes  little 
sense  to  sav  Mint  q year  consists  of  weeks  without  the 
ouan tita t ive  property. 


I 


'•11.2  Uroi^c  t;Y  a nayemont  sta  temen  ts  for  INTERVALS 

”he  = '’S  POKc  i pT  p-  ppopt  j'-]rDEETKYF  statement,  may  be  used  in  this 
Section.  nesorintior.  and  syntax  for  this  statement  are  qiven  in 
s^ot ion  ’.l. 


3.11.1  F v sternal  on^r  ties  Sta  t amen _tr  for  INI IRV ALg 

The  ? YWTNYJl,  ^'SCrlnOV,  SE1-MEM0,  KEYWORDS,  ATTRIBUTE,  ASSERT, 
SECURITY,  soun^p  and  TRACE-KFY  statements  may  be  used  in  this 
Section.  Description  and  syntax  of  these  statements  are  qiven 
in  section  ?.  2. 
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■> . 1 2 CONDinON  Z-ZliQH 

A CONDTmroN  designates  some  situation  ♦■hat  the  problem  definer 
wants  to  ilentify  because  it.  influences  the  requirements  for  the 
svst  em . 

CONDITION  (CON") ; 

(list  of  condition  names) 


7 . 1 2 . 1 F Ystem  Structure  Statements  for  CONDITIONS 

’’he  interdependencies  among  conditions  and  data  will  be  declared 
with  a DEPENDS  statement  ir.  the  following  manner. 


CONDITION 


(list,  of  condi  tion  names) 


DEPENDS  ON  

(list  of  element  or  condition  names) 


The  first  of  the  month  may  represent  some  CONDITION  for  which 
action  of  the  target  system  would  occur  deoending  on  the  state 
of  the  CONDITION  . 


3.12.2  Fvstem-Oynamics  Statements  for  CONDITIONS 

?h»  "'PUE  WHILE  and  FALSE  WIIIIF  statements  specify  those 
situations  when  the  CONDITION  is  in  the  TPUE  state,  or  in  the 
PALSE  state,  respectively.  This  information  is  presented  in  a 
comment  »ntrv  format. 

'"PUE  KWTLE; 


(comment  entry) 

SALSE  WHILE; 

(comment  entry) 

Every  CONDITION  should  have  a TPUE  WHILS  or  a FALSE  WHILE 
statement. 

A CONDITION  can  be  set  by  a PFOCESS,  an  EVENT  or  the  arrival  of 
an  INF"T. 

W A Dr  '"RUE  PY ; 

(list  of  processes,  events  and/or  inputs) 

*»PT’  FAT  SE  PY ; 

(list  of  processes,  events  and/or  inputs) 
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”he  change  in  stare  of  a CONDITION  may  also  affect  the 
nrocensinq  heirn  performed,  or  may  initiate  new  processing. 


D"CO  UNO 

(DEC  9) 

t*  cur 

(T) 

TF  1 99  7 RS  (7FGS) 

(lis4- 

of  process 

• 

, , « 

na  mes) 

BECO  wT»:o 

n*cn) 

E-.LS’7 

(?) 

TRIGG  EPS  ( TP9S ) 

(li  st 

of  process 

names) 

D^CDMI*  r. 

( !?  E C 91 

^ H n r 

r) 

TF"  V IN  ATT.  S ('""TS) 

(list 

of  process 

names) 

RTT^O  M I»lf; 

fP-T’,) 

V7.J  5*  r 

(?) 

'r,PMINATES  (TENS) 

(list 

of  process 

na  mes) 

btct  Eivn 

(RrC9) 

7?Ur 

<") 

INTERRUPTS  (I NT 3) 

(list 

of  process 

names) 

SEC''  * If  9 

prc^ 

r”I  SF 

(r) 

INTERRUPTS  (INTO) 

(list 

of  process 

names) 

■"h°  ctano 

3 in  st 

ate  of  a 

condition  mav  cause  an 

i EVENT. 

BECP  .UNO 

(SEC  91 

^ r;  fT  r? 

(?) 

CANS77?  (C  S3) 

(lis4-  of 

event  names) 

p 7P  M 

(DEC9) 

°ALS  F 

(?) 

CAUSES  (OSS) 

^ ; 

(list  of  event  names) 


A co  NDT'"  ion  should  interact  in  some  wav  with  at  least  one  EVENT 
or  PF9CESN. 


1 . 1 ? . ■*  P roi  e c t-  : a e a g e mo n t Ft  at e men  ts  for  CONDITIONS 

PE5P0NST  BLr-  °FOB L £T-DErI NER  statement  may  be  used  in  this 
Torsion.  Descvin*  i on  and  syntax  of  this  statement  are  given  in 
spc*  icn  ",.2. 

? . 1 2 . <i  System -Proper  4 ies  Statements  for  CONDITIONS 

The  9Y‘’Of:YNS,  n?  SC°  T PTTON  , SEE- MEMO,  KEYWORDS,  ATTRIBUTE, 

ASSVPT,  *soj?rrv,  SOURCE  and  TF  ACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  svn  ta  x of  these  statements  are 
given  ir  section  ?.  2 . 


PACT  I DEEP  B EQU IP  E BENTS  LANGUAGE  MANUAL 


”61  PO/MULTICS/UPI  USEE'S  MANUAL 


173 


3.13  E vr V7  Section 

An  T:'VfNT  defines  an  occurrence  of  something  within  the  system. 
The  s*ate  of  a CONDITION,  initiation  of  a PROCESS,  etc.  may  be 
defined  as  rV,T;. 

EVENTS  (rV1  ; 

(list  of  2 vent,  names) 

in  EVEN"  occurs  an  a given  instant  in  time  and  is  used  in  the 
nrobloti  statement  no  relate  the  t.hinqs  '•hat  go  on  in  the  system 
w i *■  h time. 

i . 1 3 . * ^vst  eir-bynamj  cs  7t  at°w  an  ts  for  EVENTS 


in  EVES’"  mav  be  caused  by  a PROCESS  (either  on  inception  or  on 
termination),  a ''f'MOTTION,  an  INPUT  or  another  EVENT. 

1 


C A US  E b PY  (CSO)  

(Lis'-  of  °vent  and/or  input  names) 


CAUSES  VHFN  (Csp)  BECOMES  TRITE  (T)  ; 

(condition  name) 

CA USEE  VHE'T  (C?H) BECOMES  FAI.SE  (P)  ; 

(condition  name) 

ON  TNCr'F"~'T'  (T N CP)  ; 

(list  of  process  names) 

ON  "EFvTNATION  ("F*!M ) ; 

(list  of  nrocess  names) 


An  "VFN"  may  cause  another  EVENT  or  set  the  value  of  a 

cn«jr.  »j# 


CAUSE?  (css)  . 

(list  of  event  names) 

MAKE1'  (MAK)  "RUE  ( T)  ; 

(list  of  condition  names) 

MAKES  (MAK) rALSE  (E); 

(list,  o*  condition  names) 

An  "VFN"  mav  afcem  orocessinq,  or  initiate  new  procesing. 

"■PTOOEps  (T?  0 E) ; 

(list  of  process  names) 

" E ? M.  T v A ” r ? CT’?rS) ; 

(list  of  process  names) 
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I N'’,x  ERUPTS  ( T M"S)  ; 

(list,  of  process  names) 

"he  CAUSE*  H Y , 7 N I Krlrr,'r,I  ON , ON  TERMINATION,  CAUSES,  MAKES, 
""HG^r,  TERMINATES  and  INTERRUPTS  statements  allow  ♦•he  use  of 
♦h»  optional  clauses  DEPENDING  ON  and  r0F  EACH. 

»n  PW,‘"  shoull  interact  with  at  least  one  CONDITION  or  PPOCFSS. 

"he  HAPPENS  statement  specifies  the  frequency  of  the  EVENT  in 
tf®  *rarqet  system  for  a given  time  interval. 

U A ° P E N c (HAP)  TIKES- PER  (TIMP) ; 

(system  Darameter)  (interval  name) 

HAPPENS  ’’VER  Y ; 

(svstem-parameter)  (interval  name) 

HAPPENS  [ TIT  RT*f  1 AFTER 

(system  parameter)  (interval  name)  (event) 

Every  p v*’NT  should  have  ore,  and  only  one,  HAPPENS  statement. 

3.  a 3. 2 r>roiect-vanagement  Statements  for  EVENTS 

The  FESPONST  S LE- PFC3L EM-DEFTNEF  statement  may  be  used  in  this 
Section.  Description  and  syntax  of  this  statement  are  given  in 
section  3.2. 

3 . 1 3 . 1 S vstea-nrop^rt  jes  Statements  for  EVENTS 

Tha  SYNONYMS , DE 3CP " PTION  , SEE-MEEC , KEYWORDS,  ATTRIBUTE, 

ASSEPT,  SFCUFTTY,  source  and  TP  ACF-K  EY  statements  may  be  used  in 
♦•his  Section.  Description  and  syntax  of  these  statements  are 
given  in  section  3.2. 

3.14  PROCESSOR  Section 

, A PROCESSOR  is  an  obieot  that  can  ''perform"  a PROCESS.  That  is, 

a eRorFSSOP  is  an  "agent,"  such  as  a computer  system, 
organi7ationa 1 unit,  or  person,  that  physically  acts  to  perform 
a PROCFSS. 

PROCESSOR  (PR  CR) ; 

(list  of  processor  names) 

4 * 


I 
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1 . 1 f . * rvr.'fn-S'  ruct  n re  S t.a  t e x e n t s toe  PROCESSOR  S 

! nP OC 3 S So3  nav  b»  part  of  one,  ard  only  one,  larger  PROCESSOR, 
and  i * may  have  ar.y  number  of  subparts  that  are  also  PROCESSORS. 

fnrocessor  name) 

son'1  APTS  (SUPP1  ; 

(list  of  processor  names) 

",.1U.2  p a ta  - D er  i va  *■  i o n Statemen  is  for  R?  OCZSS  OPS 

In  the  tqrqot  n v s t e m , PPCCFESQF  may  have  the  right  to  access 
information  of  certain  class  i f icat  ions  ani  categories. 

SECURI^Y-ACC r~S=o IOUT  (SAP) ; 

(list  of  classification  names 
optionally  followed  by 
classification  levels) 

"’.IN.?  System-?!*  chi*  e_c*  ur  e Statements  for  PROCESSORS 

A Pr0 CESScn  MV  CONSUL  RESOURCES,  such  as  CPU-time,  elapsed 
t ime  , or  memory. 

CONSUMES  (Cl  S3) 

(name  of  resource) 


5 " IF 


(syst  em~parameter) 


nr  n . 

(name  of  re  sou rce-usage-parameter) 

A **!•'  QCI  ? ~C-  is  the  o b gect  , group  or  person  that  performs  the 
functions  speci r ie 1 bv  one  or  more  PROCESSES. 

proper yc  fnry^  . 

(list.  of  process  names) 

p . 1 u . U Protect  - '*ar.  a cement  st  a te  men  t s for  PROCESSORS 

’"h  a ca’SPOJtSTBI^- pPOCLFv-DrFI'IFF  statement  mav  be  used  in  this 
s°ct  icn . nescri ption  and  syntax  for  this  statement  are  given  in 
section  3.2. 
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3.1 '4.?  S vs*  em-Pr  oner  » y St  £t  ® m en.ts  for  PPOCESSOPS 

"he  SYNONYMS,  D2SCFT  PTTON , SEE-KEKO,  KFYWOPDS,  ATTRIBUTE, 

ASSENT,  2 EC  U P T T Y , SOURCE  and  TP  ACE-KEY  statements  may  be  used  in 
this  Section.  Pescription  and  syntax  for  these  statements  are 
qiven  ir  section  3.2. 

i 
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7,  is  i-2ii2L. 

» srrjj.- (:*■  i s ca  me*- h i r.g  thaf  the  physical  elements  of  the  target 
ro!Knp->  in  order  *•  o carry  out  information  processing 
function  - . 

5'"^n'itCT’  (73C>  _ ; 

(name  of  resource) 

3.  I-;.1  c vs*-  e m - A r cv-  i * c-  ct  u r <»  statements  for  RES  QUPCFS 
a n ■=> sons  CE  mv  he  consumed,  or  used  up,  by  a PROCESSOR. 

c- o »i 3 qvvr;  (r‘\'  3 ") 

(list  of  processor  names) 

9 A ”■  F Pr? 

(svsfnrr!  nannptor)  (na  nn  of  resource- 

usaoe-nar  a meter) 

Resource  usage  must  ^e  measured  in  soda  unit,  such  as 
milliseconds  or  feet. 

(name  of  unit) 

7.15.2  £rojec  ti^inaje  men  t St.  a te  men  ts  for  n?SOTlRCES 

The  F’Spovct ntF- PRoni 7V-DFFINES  statement  may  be  used  in  this 
■^ec*  icn.  npscriDtion  and  syntax  for  this  statement  are  given  in 
section  7.2. 


7. is.  3 System  Statements  for  RESOURCES 

The  SYNONYMS,  PESCR' FTION,  SES-KEKO,  KEYWORDS,  ATTRIBUTE, 

ASSERT,  SFCHPI-Y,  S3 1'  FCF  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  for  these  statements  are 
given  in  section  3.2. 


7.  If  PESOUDCE-US  AGT.PAPA»ETgc  Section 

1 RESOUFCE-US AOE-PAF  AMP^EF  is  an  object  that  defines  a measure 
of  the  RESOURCE  usage  for  a PROCESS.  It  is  used  to  express 
resource  consumption  of  a PROCESSOR  performing  a PROCESS 
independent  of  what  PROCESSOR  performs  it. 

RESO  U PCE-US  AGF“?ARAVF'T’ER  (PUP) 

(name  of  resource- 
usage  -parameter) 
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i . 1 r-  . ’ F vntgiti-Archj  tcctnre  Stitsien ts  for 
;rrp-.  go  \ g tso[mt  X^1  ?S 

' m rMrnhr  velu?  for  PFFoijpcf  ueii«  way  be  associated  with  a 

liven  nporr-e  c ^ 

BFSOUP^F-TIF  AGr-n  A5.**  'TF^- VAL  7F  ( F IJ  P V ) 

(system  parameter) 


j?n  p 

(name  o*  process) 


1.16,2  Prod  a c anagement  Statements  for 
*>r  FQ  TIPC^-y^AG  r»PA?AM  ^FPS 

”6^  nF*?o!lSTRT,p-  3P7BI  i?f*.-OFPINSF  statment  may  be  used  in  this 
'■potion.  Descriptor  and  syntax  for  this  statement  are  given  in 
secf icn  7.2. 

Fyst  am-°rooerf  y ^t  ateraen  ► s for  rrsO’JP  7 5- 7 SAGS- PAP  A.tEJEPS 

The  sy«oNvvSf  n-  sc",T  E^TOF , FFS-SEKC,  KEYWORDS,  ATTRIBUTE, 

AS  1 " R'r , FFCriFT-y,  ^Ft’FPF  and  '"?  ACF-K  FY  statements  may  be  used  in 
this  cection  . Description  and  svntax  for  these  statements  are 
given  in  section  7.2, 


1.11  OKO  2££t_ion 

A Mt?IT  5 n used  to  measure  RESOURCES,  For  example,  possible 
DNTTS  would  include  inches  and  kilowatt  hours. 

fJVT"’ ; 

(ramp  of  uni*) 


7.1"’.''  system-Archi  feet ure  F ta temer: t s for  TIN _T 

A 7*7  tt  ijus*  be  associated  with  “-hp  RESOURCES  it  is  used  to 
measure. 


M p A S U r E F (FFFF) 


(list  of  resourep  nai«»s) 


i.l i.;  " codec t-^anagp me nt  Statements  for  UNITS 

Th  e PrSr>ON5I  B!  “■*  ?r  r 7 T.  rF-*DEF,I  N 3P  statement  may  he  used  in  this 
CV:»c*ion.  Description  and  syntax  for  this  statement  are  given  in 
section  7.?. 
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7.17.3  statements  for  UN  ITS 

""  h°  S YNRNYMS  , DE3CF-PTI0N,  ?s;e-MEMO,  KEYWORDS,  ATTRIBUTE, 

A SS00T,  SECURITY , SOUR C°  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  for  these  statements  are 
given  in  section  3.2. 


3.1°  PPORLFM-DEFIREB  Section 

The  ccorlF*- DE^T  NEP  is  that  person  responsible  for  one  or  more 
sections  of  the  URL  Problem  Statement.  In  most  cases,  this  is 
the  oerson  who  oriainallv  wrote  those  URL  statements. 

PROBLEM-  PE°INER  (PP) ; 

(list  of  problem  definer  names) 

3 . 1 0 . 1 Project-Management  Statements  for  PROBLEM-DEPINER 

’’ha  RESPONSIBLE  statement  is  used  to  specify  those  URL  sections 
for  which  the  Ro0BLEM-DFFINEP  is  responsible. 

RES  PC  NS  T RLE  («Esp) ; 

(list  of  names) 

» ppnpirw-oEFINFP  cannot  be  RESPONSIBLE  for  other 
PR  OR  LEM- DEFT  VIPS . 

A PF0BLFM-DFFTNr9  should  be  RESPONSIBLE  for  at  least  one  name. 

mhe  MAII  BOX  statement  SDecifies  an  address  for  the 
PROBLE^-DE^TNE?  to  which  comments  or  questions  concerning  the 
problem  statement  can  be  sent. 

MAILBOX  (BO/) ; 

(name  of  mailbox) 

A PROBLEM— DEFINE0  say  have  only  one  MAILBOX. 

3.18.2  S vs»em-Propert  jes  Statements  for  PROBLEM-  D EFI NERS 

The  SYNONYMS,  BE  SORT  PTIOf , SEE-MEMC,  KEYWORDS,  ATTRIBUTES, 

A SS E CT , SFCU PITY,  SOUPC°  and  TRACE-KEY  statements  may  be  used  in 
this  Section.  D escr  i o*  ion  and  syntax  of  these  statements  are 
given  ir.  section  3.2. 
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t 0 / " y o e o c * i o n 

A ■’.KT'O  in  a nirrsMvn  descri pti on  which  applies  to  more  than  on; 
ramp  in  tin*  problem  statement. 

m y v n • 

( me  m o r a m a ) 

"ph“  «-ext  of  th<»  myo  should  be  put  in  the  DESCRIPTION  statement. 

' . 1 n . 1 Pro  jec  *-’3  a na  g e men  t St  atemerts  for  ;i r M. 0 S 

"’he  p~spn»isT  PLr-  ’’"TBLEP'-DEFINER  statement  raav  be  used  is  this 
Section*  Descri  n*-ior  and  svnfax  of  this  statement  are  given  in 
sect  ion  3.  T. 


’.I0."  System-  oner  t jes  St  a tement  r for  2Z222 

"he  Sydney's,  ,'T?c«-:  »rroii,  keywords,  atpidutes,  assert, 

CEC,TRT"’Y , soPF'-r  and  TF*Cr-KEY  statements  may  be  used  in  this 
Cecficr.  ^>asrr:  of i o n and  syntax  of  ttojjo  statements  are  given 
in  section  3.2. 

"he  ArPTTF'  s ■*■  af  emen  t.  soecit'ies  those  URL  names  +o  which  the 
M"'10  pertains. 

APPLTT’P  (APP)  ; 

(list-  of  names) 

A MENC  cannot  ?P?tY  * o another  KFMO  name. 

A VT7MO  rhould  A^PLY  *o  at  least  two  names.  Otherwise,  the 
information  could  be  presented  in  the  DESCRIPTION  statement  for 
the  name. 


■>.  2C  "hr  2221 2:.  loot  i on 

"he  rFyNE  section  < s us^d  to  specify  information  about  snecial 
tVDes  of  names  the*  do  rot  have  their  own  ”RL  sections. 

The  format  o*  *h»  "“'FIN"  section  is: 

PTPT  N r fDEP)  name-type; 

(UPL  names) 

'Jhoro  the  name-type  mav  be  one  of  the  following: 

A"'T°7FU'T"~  (AT”D  - defires  a characteristic  or  mode  of 

the  targef  system. 

* t^o  - pp'- r_v * t n:  (AT  ” V ) - defines  a particular  value  for  an 
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CLASSIFICATION  (CIS) 


XEYWOFD  (KEY)  - 

matlpcx  (nox)  - 

SECURITY  (SEC)  - 
SC'ICCF  (S?C)  - 


associated  ATTPIBUTE. 

can  be  associated  with  data 
processes  and  processors. 

can  be  related  to  names  for 
retrieval  and  analysis  purposes. 

defines  an  address  for  a 
PRO  EL FK- DEFINE? . 

defines  security  status  for  one  or 
more  UEL  names. 

defines  a reference  for  additional 
information  related  to  objects 
being  described. 


SUBS  E TT I N G~ C F T?  E P Tn  w (SSCV) 


defines  some  data  objects  whose 
value  is  used  as  the  criterion  for 
segmenting  a SET  of  data. 


c Y'5  T F v-  n A F A v p r,rn  (EYSF) 


(T  KEY)  - 


defines  an  object  whose  value 
influences  the  size  of  particular 
aspects  of  the  system. 

can  be  used  to  relate  names  which 
exist,  in  different  data  bases. 


1.?n.1  Evstom-s*  rnc»  uro  Eta te.nen ts  for  the  DEFINE  Section 

C’UB  E rTTT  NC-c  f '""r  j tok  names  may  be  defined  to  apply  to  one  or 
more  Sr"S  via  the  SU 8SETT TNG-CP ITER TON  statement. 


(.eecn) 


(list  of  set  names) 


No  other  name  *-yoes  in  the  DEFINE  section  mav  use  this 
s*a*  siren  t. . 


1 . 2r  . 2 r a ta - D er  i va *•  i on  Statements  for  the  DEFINE  Section 

* 

"he  MAINTAINED  sta'seen*  specifies  those  PROCESSES  that  maintain 
. SMBsr'r'rTNG-CFITEPTCtT  for  organisation  of  a SET. 

MAINTAINED  (dm) ; 

j . (list  of  nrocess  names) 

Th  a MAINTAINED  statement  allows  the  use  of  the  optional  clauses 
DEPENDING  ON  and  FOP  EACH. 

i 

i 
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*'ain  tera  nee  of  S UULF  jji^-cPlTEPIOV  involves  nlacement  Df 

, isr'rc  ond  OUTPUTS  j_n  Drcper  SET??  accor  ng  *:o  the 
values  of  the  ri;  P5r7TTrr*.-rPT  TFRIOK  contained  wir  ir  them. 

Vo  other  nano  ‘vops  in  the  PEPIN?  section  may  use  .his 
3 t at emor  t. 

?.?r.  3 S vs": orn-oi  ?.o  ? t aterron*  s for  DEFINE  Section 

*YS??F-PAFAvi  -<rRS  a^.d  at’TPTBUTE-V^T  UPS  nay  he  defined  to  have  a 
VAL"F  or  range  o*  V?  T U?S  associated  with  them. 

Th“  VAI.U*  sf atemer.t  is  used  +o  define  the  numeric  values  a 
?Y'>Tr V- PARA’*'" mT'P  may  have. 

VAL'1?-  (VAL) ; 

(integer  value) 

°nlv  positive  integer  values  may  be  specified.  Decimal  numbers, 
negative  numbers,  etc.,  are  not  acceptable. 

A range  of  values  may  also  be  specified. 

VALVE?  (y  AT,)  THpn ; 

(minimum  value)  (maximum  value) 

Again,  the  VALUES  must  be  positive  integers.  The  minimum  value 
must  t e less  than  the  maximum  value.  POSINP  and  NE3INF  may  be 
used  to  represent  positive  and  negative  infinity,  respectively. 

nnly  cne  VALU”  statement,  of  either  of  the  forms,  may  be  given 
to  describe  a narticular  SYSTEM-FA FAMETEF. 

No  other  name  tvnes  in  the  DF?INr  section  raav  use  this 
st at  e»e»n  t . 


3.1V.U  Project- Vi anagement  Statements  for  the  DEFINE  Section 

The  PESPON3IBLE-PFORIFM-DEPIN5F  statement  may  be  used  in  this 
Section.  ^ascription  and  syntax  for  these  statements  are  given 
in  section  3 . 2. 

3 j . c System-Propert  jes  Statements  for  the  DEFINE  Section 

"he  SYNC  N YM5  , nE  SCE  T PTION  , SE2-MEMC,  KEYWORDS,  ATTRIBUTES, 
ASSEFT,  S?CUPI"Y,  soupce  and  7PACE-KEY  statements  may  be  used  in 
this  Section.  Description  and  syntax  of  these  statements  are 
oiven  ir.  section  3.2. 

The  APPLES  statement  may  be  used  for  MAILBOXES,  SECURITIES  and 
SOURCES  to  soecifv  the  UP!  names  that  they  apply  to. 
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A-,r,TT?S  ( A P 0 ) 


(list  of  names) 


rxcent.ions  tha*  SECURITY  may  not  have  SECURITY,  and  SOURCES 

mav  not  have  a S ogre?. 


1 

4 


3.21  ’he  !)*■  SI 'IN  AT’  Section 

’he  DFrrnwA’e  sectior  consists  of  one  statement  which  specifies 
that  a given  name  is  to  he  made  a SYNONYM  of  another  name. 

"his  facili*-avea  vhe  advantage  of  using  short  abbreviations  when 
referencing  a Darticular  object. 

r‘E3I’Nt’r  (r>r”g> AS  A SYNONYM  (SYN); 

(a  name) 

A name  can  hav*  anv  number  of  SYNONYMS,  but  a name  can  be  a 
SYNONYM  for  only  one  other  name. 

wo  other  sta  emon  + s are  allowed  ir  this  section. 
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n?T,  i r-  a very  flexible  and  comprehensive  languaqe.  Most 
situations  can  bo  represented  or  expressed  in  URL  in  more  than 
one  wav:  each  of  which  is  syntactically  correct.  However,  the 
different  representatives  may  imply  different  semantics  which 
mav  or  may  not  be  what  the  analyst  intended.  This  section 
describes  a number  of  situations  in  which  alternative  methods  of 
expression  are  possible  and  outlines  the  implications  of 
different  strategies. 


a . 1 Specifying  the  ” System"  Boundary 

Tn  '’PI,  a up  A data  base  contains  the  description  of  one  system. 
Each  system  has  a boundary  and  the  system  description  may  be 
thought  of  as  consisting  of  t*o  parts: 

- the  specif icat ion  of  what  goes  or  inside  th°  system. 

- the  specification  of  what  crosses  the  boundary. 

Alternative  strategies  are  possible  in  the  order  in  which  these 
parts  are  specified.  nne  possibility  is  to  delineate  the 
boundary  first.  The  second  is  to  describe  the  ” interior”  of  the 
system  without  iientifying  the  boundary. 


1)  Specifying  the  Pound  ary  Fi^st 

A firm  boundary  is  obtniPed  wilPn  INTERFACES  are  defined  and 
their  communication  with  the  system  is  specified  by  naminq 
INPUTS  an!  ou^pu^S.  I*  is  assumed  here  that  INPUTS  enter  the 
system,  ini  o,,"’PU'r~  leave  the  system,  in  some  physical  form 
containing  data  values.  The  constraint  ip  u«T.  is  that  an  INPUT 
can  only  come  from  an  IVTFFF'CE  and  OUTPUTS  only  go  to  *n 
Xfjmm  eyr-CT.  Inside  the  system,  a number  of  PROCESSES  may  be 
names,  each  on^  of  which  uses  data  from  the  available  sources  - 
INPUTS,  "UTI'rT_3  or  PFTS,  or  from  unspecified  sources  - 1P0UPS 
and  ELEMENTS,  fco  derive  and  update  data.  A PROCESS  may  USE  data 
rrom  arv  of  t^ese  sources  or  DEPIVFD  from  any  PROCESS;  and 
si  mi  lari  V,  lata  DRIVED  by  on  5 oROCFSS  may  be  nSED  by  any  number 
of  o*-her  P°0C?SSE‘J. 

0nQ  hnp e f i t of  this  approach  is  *hat  the  problem  statement  can 
bo  rhecV'V  for  completeness,  e.q.,  that  each  INPUT  is  GENERATED 
bv  rome  INTERFACE  ».nd  °rCEIVED  by  at  least  one  PROCESS  and  that 
each  OH?  PIT  is  GENPR.*”,ED  by  some  PROCESS  and  RECEIVED  by  at 
least  or.o  ’v^nujic".  Another  benefit  is  that  the  description  of 
the  INPUTS  and  OUTr>”Tc?  can  be  aqreed  to  by  the  relevant 
PEACE. 

A disadvantage  of  *his  approach  is  that  an  T V^FR FACE  is  not  a 
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pmrpc;?'  and  ,m  obdr-ot  that  is  an  INPUT  to  the  system  cannot  also 
bo  IT)  nfl  rrr>n7  . 


7)  ~pg  e j f v i *•  o the  I nt  er ior  of  t h e ^yst  ero  First 

Tn  some  cw"fi(  it.  may  be  desirablr  to  delay  specifying  the 
system  bonriarv  until  ♦h<'  interior  of  the  system  has  been 
describe'}.  ‘"his  can  he  don?  by  not  identifying  any  INPUTS  and 
orT-pri-rc,  but  instead,  defining  *hose  PROCESSES  that  USF  and 
o-prirTT  an1’  defining  data  in  terms  of  "VTITIES,  SETS,  GROUPS 

an]  ~T  fm  "N'TS  . wh->*-  would  be  an  INTER  FAC F in  the  previous  case, 

now  can  be  id->nvitioa  as  a PROCESS,  and  therefore,  the  object  in 
the  real  wor1  1 can  use  data  from  ar.v  source-derived  data  which 
can  he  used  by  a nv  other  PROCESS. 

'"he  advantage  r>F  ►hir  approach  is  that  any  of  the  objects,  e.g., 
PROCESS,  can  both  n?T  data  and  DERIVE  data  and  that  a given 
collection  of  da*-*  identified  as  an  rNT!?y  can  be  both  USED  by  a 
nnor?  = s an  1 be  n^rv?!)  by  a F3CCESS  fin  addition  of  course  to 
heino  UP r A" SO). 


4.0  Assj  gnm^r  - of 

,,CL  requires  that  each  name  (object.)  used  in  the  system 
description  b«  of  a certain  type.  there  are  29  types  available 
of  which  2*  arQ  defined  by  their  own  sections  and  the  other  9 
are  defined  hv  t^a  DFFTN?  section. 

"he  assignment  of  a tvoe  to  a name  is  crucial.  Statements  that 
can  be  made  about  an  object  and  its  relationship  to  other 
objects  ar-  limited  t0  those  available  in  the  object's  section, 
"n  some  situations  the  choice  of  a type  for  a particular  object 
ir,  clear*,  in  other  situations  there  may  be  several  legitimate 
choices.  This  section  liscusses  the  situation  ir  which  there 
are  alternatives. 


4 . . 1 TN75RF  ACTS  Versus  PROCESSES 

“n  very  general  terms,  a PROCESS  is  an  obdeot  which  is  part  of 
tho  target  system,  and  which  operates  on  data  values  which  it 
"SPS  to  DE^IV"  n»v  data  values.  The  PROCESS  can  also  UPDATE 
data.  The  3a*ra  which  is  used  bv  a PROCESS  can  come  "from"  any 
other  PROCESS,  and  the  lata  which  is  DERIVED  can  be  USED  by  any 
other  PFr,c"cS. 

tn  contrast,  an  IU'"R’FPACF  is  a unit  outside  the  boundary  of  the 
target  system  which  can  produce  data  for  the  tarqet  system 
(CE*i  FR.A " F an  and/or  receive  data  from  the  tarqet  system 

("FCETV*  an  OU^pyt)  . 

»n  object,  should  be  assigned  an  TNTFRPACE  type  name 
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or.lv  if  it  inf?nr‘s  wiM.  th°  taruet  svs tem,  namely,  that  it. 
rfi.ll  o-!«-hor  F frvn/v  OT  gp  jjfjp  A",F  data.  Otherwise,  the  ob  lect 
should  be  assign  ed  the  name  type  "p?0CE?S." 


'j  ;^pr  S , onj’PUTP  and  F N T I T I ; F 

:,,r>fiTcf  0riTnr»-r-  1Tla  F\TtTIFS  are  types  of  obiects  which 
"contain"  or  "carry"  se+-s  or  collections  of  lata  values, 
conceptually,  tv,«  na  me  car  represent  bo*  h the  "container"  or  the 
collection  of  data  values  contained  in  that  container, 
furthermore,  ^h*  container  can  he  regarded  as  ohysical,  that  is, 
a card,  a tape,  a record  on  a disc,  «tc.,  or  it  can  be  reqarded 
as  a loci  cal  construct  which  may  or  may  not  be  physically 
imnl°meeted  tha*  form. 

»i  o b dec t shoull  be  designated  as  in  iNPfl’"  if  what  is  to  be 
specific*  is  a container  with  data  values  coming  into  the  target 
syst.e*  f rom  outside,  i.e.,  from  an  TNTEFFACE. 

Another  .distinguishing  characteristic  of  INPUTS  and  OUTPUTS  is 
that  when  interpreted  as  "containers"  of  data  values  thay  are 
temporary  as  far  as  the  target,  system  is  concerned.  There  may 
he  multiple  instances  op  the  particular  INPUT  coming  in,  but. 
once  it  in  received  by  a PPOC SS^,  the  particular  instance 
dis  appears. 

For  example: 

INPUT  time-card 

’ Jin]  i»s  tha*  ‘‘h Q system  will  receive  objects  of  type  INPUT  which 
are  called  time-card.  The  number  of  individual  'time-cards* 
which  arrive  is  specified  by  the  statements  such  as  HAPPENS. 

Similarly,  an  obl^t  should  he  designated  an  OUTPUT  if  it  is  a 
"container"  oc  lata  values  an l if  it  is  specified  to  leave  the 
Mr-iet  system.  Again,  there  may  be  multiple  instances,  each  ona 
of  which  has  to  qFvwSA,'T:0  and  each  leaves  the  system.  Once 
individual  instances  of  the  output  have  left  the  target  system, 
thov  are  not  considered  part,  of,  or  accessible  to,  the  target 

s vst cm . 

“h-*  reasons  for  dist  i nuuisbi ng  Inputs  and  outputs  from  ENTITIES 
an  1 open?^  is  tha*-  (“M  eventually  the  physical  medium  on  which 
tbav  anroar  an^  their  representation  will  have  to  be  specified, 
ind  (?.)  th*'  source  and  destination  can  he  related  to  INTERFACES, 
and  (3)  and  volume  can  ba  specified  for  INPUTS  and  OUTPUTS 

bijt  rot  for  croups, 

'n  rr  u^T*y  i r.  a "-ontainer"  of  data  value;  in  this  respect,  it  is 
’anivalon-  to  an  TPUT  or  OUTPUT.  Uowevor,  it  differs  from 
r»!Pf,"S  an-*  outputs  ir  that  it  ia  internal  to  the  system  and  it 
nersists.  }£ora  , an  individual  instance  of  an  "NTITY  must 
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be  created,  i.®.,  nEFT'^r., 

Aqain,  the  r,N'r7'!,v  »av  b®  a "loqical"  collection  of  data  values 
or  1 t may  h°  a "physical"  collection.  when  it  is  designated  as 
a physical  collection,  it  will  probably  be  implemented  as  a 
logical  record  or  physical  record  which  is  maintained  by  the 
systo-n  jn  som®  way. 

"h-'r^forp,  an  obiect  which  is  a collection  of  data  values  that 
is  internal  to  v he  tarqet  system  and  persists  in  the  system, 
should  be  desiqnated  an  FNTITY  rather  than  as  an  INPUT  or 
OTT-PTT. 


U.2.  3 yN ^I"1! 7 S Versus  GROUPS 

An  EN-'I'rY  is  a loqical  collection  of  data  values.  Data  values 
ar’  particular  instances  of  ELEMENTS  or  GROUPS.  The  data  values 
included  in  the  collection  are  specified  by  the  CONSISTS  of 
statement.  A G^on?  is  also  specified  as  CONSISTING  of  a number 
of  GROUPS  and/or  data  ELFMINTS . 

Th®  maior  distinction  between  ENTITIES  and  GROUPS  lies  in  that 
"MIITY  is  a container  of  values  of  the  ELEMENTS  of  which  it 
COM F IS’r S . A GROUP,  on  th®  other  hand,  is  merely  a notational 
converienc®  tor  naminq  a set  of  data  of  which  it  CONSISTS. 
Whenever  ^he  ana lys*  finds  that  a number  of  data  ELEMENTS  appear 
in  a number  of  situations  together,  he  car  simplify  his  writing 
time  and  analysis  * i me  by  defining  the  collection  as  a GROUP. 

o*-her  differences  between  FNTITIES  and  GROUPS  are  the  following. 

11  GROUPS  can  be  CONTAINED  in  ENTITIES,  INPUTS  and  OUTPUTS, 
but  ENTITIES  cannot. 

2)  Entities  (and  INPUTS  and  OUTPUTS)  car  be  CONTAINED  in  SETS, 
but  GPOU DS  cannot. 

7)  ENTITIES  can  CONSIST  of  GROUPS  but  not  of  other  ENTITIES. 
GROUPS  car  CONSIST  of  other  GROUPS,  but,  of  course,  not  of 
FNTITTSS . 

4)  GROUPS  can  be  used  as  S UR  SETTING-CF  ITER  I A of  SETS  and  t.o 
IDENTIFY  FURIES,  but  ENTITIES  cannot.  ENTITIES  can  be 
RFT  A "ED  via  RELATION  statements  and  have  ASSOCIATED  data 
consistinq  of  GFOUPS. 

5)  As  far  as  !5POCr,ssrc  are  concerned,  the  same  statements  that 
car  b®  mad®  about  EN"ITTFS  can  also  be  made  about  GROUPS, 
though  when  fh=  FN-Tty  is  used  in  a statement,  the 
appropriate  statement  about  the  ELEMENTS  or  GROUPS 
CONTAINED  in  the  EN"T"Y  must  also  be  made  (See  Table  4.1). 

6)  “Qt  h T’N'"T"TTC  and  GROUPS  can  have  SYSTEM-PARAMETERS 
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issnc’i  t»l  wi*- h *-hp  CONSISTS  statement.  Iu  addition,  the 
"'’"■'’TV  con  hav^  a r*  FD I NA  I.TTY  and  VOI?"ILITY  stamen  on  t 
whi  le  a ;■  O'tn  cannot  . 

7*io  problem  '3°fin“T'  should  snecifv  an  obiect  to  be  an  ENTITY 
wH  »r  he  wishes  1 0 r°fer  a number  of  ELEMrNTS  as  a unit. 


t . 5 Xri— £ii2Ii  -t  J? £' 13 .Li 2 11 .51: i 22. 

"11  relationships  : * PEL  a1-®  precisely  defined  by  statements. 

Tn  manv  cas®s,  tnlv  op*  will  be  leqitiirate.  In  some 

ras°s,  however,  *1'»rp  may  he  a choice.  These  situations  are 
outlined  in  thin  section. 

h.  i.  i ZL££i irz C1Z1ZILIZ1  v^c sus  ,?Eyc’/dPDATEE/o?t)  ivss 

1)  PEC  ETV  ? S /o"  ■}  - ; ^ -vjc  c?n  only  refer  to  INPUTS  /OUT  PUTS 
whereas,  r,c'  E5/r*  rp«  -y  ~/n  ER  T VP  E car  onlv  r^f^r  to  "data." 

2)  "S;  “ it  olios  that  tho  data  value  of  what  is  beinq  USED  must 
be  avail  iM  ^ . 

" Pr  a~te;  iniolies  that  “he  da*a  value  must  be  CONTAINED  in  an 
ITY . 'l"FIYpe  implies  a value  is  computed. 

*)  When  T«nM-e-  rf<?i?n,  OUTPUTS  are  DERIVED, 

SETS  are  MSgr,  "PD AT?D  or  PEFIVED, 
pri'T’c  a-e  P'*  E P,  T’?D»TED  or  DERIVED 

‘his  implies  “hat  tvP  data  values  in  these  "containers"  of 
data  values  are  beinq  referred  to. 

'11  '•'hen  T’OUPS  are  'JEEP,  U PDATE  or  ovpiVED  a“  least  on® 
elrment  in  t.h®  GFoup  is  referred  to. 

8)  T*  e allowable  syntax  for  which  statements  can  affect  which 
cb d nc* s is  shown  in  "able  2.4. 3.1,  "he  meaning  of  the 
statements  is  mhown  in  "able  2.4.3.  2* 
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5.  ACHT^VTKG  GC  'P  nccrHFNmA  TON 

Pocu  mer  *■  ation  of  the  taraet  system,  of  its  interfaces  with  the 
orqa  n i^a  t ior.  ar.i  ifs  environment,  and  of  Hie  system  development 
nroiect  is  used  for  different  purposes.  Figure  5.0  outlines 
some  characteristics  cf  present  manual  documentation  and  some 
d»sirabl  =•  characteristics  that  are  achievable  wi*h 
com  p u ter-ai  d ed  d ocu  m ent  at  ion  . 

To  achieve  t h°  potential  benefits  cf  computer-aided 
documentation  reunites: 

- a formal  language  which  permits  relationships  to  he  precisely 
defined. 

- a computer  nr ou ram  which  provides  a method  for  enforcing 
correct  use  or  f h°  ^orma]  language. 

- qocd  procedures  to  s®  followed  by  the  analyst. 

-ha  i ip*  o*  ti,aye  is  important  since  no  matter  how  good  the 
language  ar-'1  the  computer  software,  tho  benefits  will  never  be 
attained  unless  the  tools  are  used  properly. 

"n  Mention  h . 1 f he  characteristics  of  good  documentation  are 
described  mi  "o* hoi  ? are  .suggested  by  which  the  analyst  can 
achieve  then  ueinn  r,PT,/TTt5A.  Section  5.2  summarizes  the  check's 
for  preciseness  and  consistency  which  are  performed  by  the 
Anilvzer.  ch»rts  which  the;  analyst  car  perform  using  the 
outputs  available  ercri  the  Analyzer  are  described  in  Section 
c.  ?. 


c . 1 Cha racket j.sf^c2  of  Goof  Documentation 

usually,  * he  ara  Ivst  is  responsible  for  producing  documentation, 
'’’his  soc^ion  nFli^r,  some  magor  attributes  of  good 
'iocu  ment  at  i or  a-'l  indicates  how  ar  analyst  may  use  UPL/UIA  to 
a ch  i ev“  t ve»  . 


K.1.1  Hr  d ar s t an d a b i 1 i t y 

’'oon  mop  ta*-i  on  with  this  ch.aracteri  st.  ic  is  in  an  easy-to-read 
format  ard  is  presented  at  a general  enough  revel  so  that 
persons,  no  matter  what  their  backaround,  should  b»  ahle  to  read 
and  ccmprehop.  1 * he  material  within. 

Cjnorts  car'  b"»  oep, -rated  from  the  problem  statement  in  several 
common  formats,  e.g.,  flow  diaqrams,  matrices  and  at  different 
l0v«ls  of  detail.  For  example,  it  is  often  desirable  to 
initially  present  high  level  oblects  and  have  subsequent  reports 
present  mora  and  more  detail  about  these  obiects  until 
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°v»r y*hinq  is  ^••scribed  ir.  fe-ms  of  their  lowest.  level 

cons’-  i tu  erf  s . "he  analyst  can  choose  the  ordering  and  content 

of  the  r e po r t s . 


nree  (>n* 

Manual 

l'oci  mentation 

'lard  to  Un  d e r s*  a n d 
Ambi  guou  s 
Tncnn.'-isfi-"’* 

Tnc.ompleto 

'ncorrec  *- 

difficult  to  Analvre 
and  E v a 1 a a t e 
Hard  to  Modify 


"e  si  r a b ] o c ha  ra  c t e r i s t i c.s 
of  Computer-Aided 
Pocum  en  ta  ti_on 

Understandable 
Pr  ecise 
Conr.i  stent 
Co  mpl et  p 
Correc  t 

Computer-Aided  Analysis 
and  Evaluation 
Compu  t en  - Ai  ded  tip  d at  i ng 


figure  5.  r Characteristics  of  Documentation 
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Documentation  with  this  ouality  must  have  all  relevant 
terminology  explicitly  defined  so  that  information  presented 
cannot  be  misinterpreted. 

a computer  interpreted  language  must  have  rn  accurately  defined 
syntax.  The  reserved  words  in  the  syntax  of  UFL  are  used  to 
Inscribe  different  objects  and  the  relationships  between  the 
objects.  Definitions  of  all  reserved  words  allowed  in  the 
syntax  are  fixed  so  that  all  relationships  presented  in  the 
documentation  (UPA  reports)  are  exactly  the  same  as  those 
initially  specified  by  the  analyst  (i.e.,  there  can  only  be  one 
interpretation  of  the  information). 


5.1.9  Consist  ency 

documentation  which  is  "consistent"  presents  all  the  material  in 
proper  context  and  does  not  have  statements  that  are 
conflicting,  contrad ic*orv  or  inconsistent. 

mhe  context  in  which  a particular  object  is  to  be  used  is 
defined  by  thQ  «s«:  via  DPI  statements  which  will  be  stated  in 
the  UFA  data  base.  Any  attempts  to  use  the  previously  defined 
object  in  a conflicting  context  will  result  in  an  error 
diagnostic.  "h^refore,  use  of  UFA  maintains  consistency 
throughout  the  documentation  . 
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5. 1 . u Com  pie ss 

~’r>  documentation  must  present  the  material  in 

su^ficien*  detail  90  that  no  reference  to  outside  sources  is 
nodded  for  a '■horouuh  understanding  of  the  subject  matter. 
rvar  v necessary  ni»rf  of  information  must,  be  available  and  no 
relationship  must  be  left  danglinq. 

HPT,  allows  a number  of  relationships  and  objects  to  be  defined 
*0  describe  an  I nf  or  ma*-i  on  °tocessinq  Svstem.  The  UPL 
statements  offered  provide  a thorough  outline  of  what  should  be 
incorporated  into  the  documentation  of  an  IPS.  The  statements 
in  H 51  facilitate  the  enforcement  of  completeness. 


c.  1 . 5 no  r rec  v nn3  s 

~"r>  he  "correct,"  the  analyst  must  insure  that  all  relationships 
snacified  in  Mi“  documentation  are  valid,  and  that  all 
information  recorded  is  true. 


che  syntax  rul°s  enforced  by  HP  A insures  that  all  relationships 
in  the  documentation  are  valid.  "hough  it  is  impossible  to  know 
whether  the  information  recorded  is  true  or  not,  many  of  the 
reports  available  car  present  the  information  in  a format  easy 
for  the  analvs*  to  check  for  errors  (e.g.,  misspellings, 
incorrect  narrative  descriptions,  «>tc.)  . 


r. 1 . f.  An  alvzabil itv 

Hocu men4-  ation  which  is  analvzablo  must  be  organized  in  such  a 
wav  rhat  an.v  information  not  explicitly  stated  in  it  must  be 
easily  derive  1 f hrotiqh  soire  procedure. 

Firca  all  ’?r  L are  stored  in  a data  base,  all  data  is 

easily  accessed  can  be  presented  in  the  form  of  a UR  A 

renort.  "n  addition,  any  now  developments  in  analyzing  the 
information  (e,e . , Cost/Benefit  Analysis,  etc.)  can  be 
incorporated  into  *he  existing  UFA  package. 

5.1.7  Pase  af  *0  !j  f j cation 

documentation  which  ;s  easy  to  modify  must  have  sufficient 
ind«=>xi"q  facilities  so  that  all  occurrences  of  a given  item  in 
fhe  documentation  may  be  referenced  if  and  when  a change  to  the 
i*em  is  reouir^i. 

Decaus®  the  ’''formation  used  in  deriving  URA  reports  is 
contained  within  t;ia  rjp  a ^ata  base,  anv  modifications  to  thq 
data  bas°  will  b«  reflected  in  reports  produced  after  the 
chan  te.  'TP A offers  several  commands  to  modify  the  data  base, 
Anv  reports  generated  after  the  modifications  will  be 
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up- to- da  te. 


*.2  Checks  Carried  0 u t by  the  Anal vzer 

'’or  the  most  par4-,  the  characteristics  of  good  documentation  can 
be  realized  wh°n  t.b.**  documentation  is  generated  by 
com on tor- ailed  means,  "recissness,  consistency,  and  correctness 
are  all  checked  bv  the  Analyzer  as  new  information  is  added  to 
*he  da*-a  base  or  da*-a  is  modified  in  it. 

UFA  can  produce  several  hundred  diagnostic  and  error  messages. 
Each  is  identified  by  a number.  The  complete  list  is  given  in 
the  "User  Feouir  emend,  s Analyzer  riser’s  Manual"  in  numerical 
order  tc  facilitate  correction.  Here  the  error  messages  are 
analyzed  in  tprar.  of  how  they  contribute  to  good  documentation. 

5.2.1  Checks  £2  Free iseness 

A considerable  portion  of  th®  error  detection  facilities  in  the 
Analyzer  are  used  tQ  check  the  "preciseness"  of  new  UPL 
statements  beina  added  to  the  data  base.  (This  is  done  each 
time  Tp-finy,  is  initiated.)  The  Analyzer  atust  check  that  the 
syntax  is  correct,  and  that  the  user-defined  names  given  in  the 
nav  statements  are  consistent  with  names  already  in  the  data 
base.  If  either  of  these  conditions  fail,  an  error  diagnostic 
must  te  genori*-ed  bv  the  Analyzer  to  inform  the  user  that  the 
information  to  be  store4  in  the  data  base  was  ambiguous  or 
inconsistent  with  the  information  already  in  the  data  base.  Ho 
ambiguous  or  inconsistent  information  is  stored  in  the  data 
base . 

a)  ?tT!4ax  Errors 

Freaking  anv  of  the  syntax  rules  of  'JPL  will  cause  the 
Aralyrer  to  generate  one  or  more  error  diagnostics. 

Typical  syntax  errors  are: 

- us-*  or  i’  legal  characters. 

- misspell  inn  of  UP  A reserved  words. 

- omission  of  semi-colon  to  terminate  line. 

Table  *,2.i  presents  a complete  list  of  diagnostics 
rro'’’icei  when  a svntax  error  is  encountered. 

b)  Incorrect  Use  of  Names 

I*  is  yory  important  ►hat  once  a name  is  defined  and  has  an 
associate*  name  type  alor.a  with  it  (e.g.,  PFOCESS  or  SET), 
the  name-  can  only  be  used  in  the  context  in  which  it  was 
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defined.  Th“r°f  or^,  a name  defined  to  bo  a PROCESS  cannot 
also  Hp  mso  1 to  define  a ^FOMP  of  lata.  Likewise,  only 
♦ho so  r e La f ion s h i 03  specified  bv  the  "User  F equirem  an  ts 
language,  Language  Reference  Manual"  can  be  used  to  relate 
to  obiacfs.  ’’or  example,  a f’SIE  relationship  between  two 
' ^OCFS'3  nam-»s  is  nof  allowed  and  any  attempt  to  specify 
this  would  cause  the  Analvzer  to  generate  the  diagnostic: 

■'"ipT  n F ELEMENT  , f> r 0 M F , INP'JT,  ENTITY  OR  SET 

"able  n . ?.  1 . T r»res«nts  a complete  list  of  the  errors  that 
can  b®  enco unk a r°d  when  incorrectly  using  names. 

5.  1.  2 rh ®ck s l5§oci  a .t  e_1  with  consistency 

ts  met  s * a *•  o m^n f s ar  ® beinn  added  to  the  data  base,  the  Analyzer 
also  ch.’scvs  that  the  n^w  relationships  being  specified  are 
consistent  with  the  information  alrealv  in  the  data  base.  In 
tn  a previous  section,  the  Analyzer  was  shewn  t.o  check  that  once 
a name  was  defined  t 0 ve  a given  name  tyDe,  it  could  not  be  used 
in  a conflicting  context  (i.e.,  as  a different  name  tvpe)  . The 
Analyzer  must  also  choev  that  the  relationships  specified  for  a 
given  nam®  do  not  conflict.  For  example,  if  an  ENTTTY  was 
defined  to  have  a C*Ff'TNAITTY  of  ICC,  it  would  be  illogical  to 
also  sa.v  that  its  CAFOINALTTY  is  50.  The  Analyzer  will  detect, 
these  tyPt»=!  of  inconsistencies.  The  Consistency  Error  Messages 
are  listed  in  "a  ole  r .2.2 . Table  5.2.2.  1 presents  the  various 
inconsistencies  detected  bv  the  Analyzer  according  to  name  type 
and  relationships  within  the  system  description. 
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Diagnostic 

Nirx  fam*-  ""oo  long 

N’L"’y  '"or'  vo""  foun c p f fo  ■; k fnd-ok-filf 

TV>pc  -?nrp  OPENING  DAT'  PA*  E FOR  - 

NT/*Y  rtip-oF-DTLF  IN  MIDDLE  OF  COB  KEN  7 

FCAN"  ILLEGAL  CHARACTER  - IGNOFED 

CFTIC7  NO  APPLICABLE  PRODUCTION  - SYNTAX  SPPOP  - START 
^KIPPING 

FTACK  ""T.  LEGAL  EYE  BO  L PA  IP  - SYNTAX  ERPOF  - ST  AFT 
SKIPPING 

COvF NT  FND-CF-FII.F  IN  COMMENT  SNTP  Y 

FUME"  SSCN  IS  ONLY  LEGAL  TYPE  TV  DEFINE  SECTION  WHICH 
CAN  HE  MAINTATNrD 

VLT~T  ONLY  SIEGLF  VALUE  OF  RANG"  ALLOWED  - IGNORED 
OTHERS  V ALt,fs  ONLY  LEGAL  FOR  FLEMENT,  SYSPAP, 

'JF  A "’TFT  BUTE- VALUE 

CLcr  A PUNCH-  NOT  ALLOWED  IN  THIS  IMPLEMENTATION 

'’LIST  NAM?  NOT  r>A  F T CF  HEADER 

T’WLTS?  rtKtNO"'  HAVE  K2YW0FD  FOP  KEY WOFD 

PWLTST  CA N 1 O'"  HAVE  SECURITY  FOP  SECURITY 

PWLIS"1  CA  N NO"  H AVE  SOURCE  FOF.  SOPPCF 

P WL I e ” SYNONYMS  off  I.Y  APFITED  TC  »!  RST  KANE 

»fnrG  AP^T.IEF  STATEMENT  ILLEGAL  WITH  THIS  NAME  TY  PE 

ILLS?  ILLEGAL  STATEMENT  IN  THIS  SECTION 
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"r:or 

'lunbpr  Piaarostic 


25 


1}1 

I 1 C2 

!•  119 

304 
o «.7 
oqq 

21 7 
211 
215 
21  7 
213 

734 

335 

235 

f 240 

i 2'4 1 

46 
4 7 
49 
5T 
67 


HEAD  IV V A LI 7 HEADER  STATEMENT  - STATEMENTS 

WILL  BE  IGNOPFD 

OWLIST  MUST  0^  SUBSETTING-CRITEPION  NAME 

NLT3T7  vAf'F  ALFEADY  USED  IN  DIFFERENT  CONTEXT 

VLTST2  DAVE  ALREADY  US ED  IN  DIFFEPENT  CONTEXT 

CT.P3  A pI  L F - NOT  ALLOWED  IN  TfllS  IMPLEMENTATION 

NLIS T VA*F  PREVIOUSLY  USED  DIFFERENTLY  - IGNORED 

OETV  N»r?  ALREADY  USED  IN  DIFFERENT  CONTEXT 

SETS  YN  CANNOT  BE  MADE  SYNONYM  - DIFFEPENT  TYPES 

CHKCCM  STACK  OVEPFLOW  WHILE  WALKING  CONSISTS  STRUCTURE 

pp-MTi*!  NO  NAMES  IN  DATA  EASE 

CT9FFS  N»"F  MUST  BF  ENTITY  NAME 

CTHE77  NAME  "UST  PF  ENTITY  NAME  9EFOFE  VIA 

OTHERS  NAME  MUST  BE  RELATION  AFTER  VIA 

CLSp<~A  PIT.**  NOT  ALLOWFD  IN  THIS  IMPLEMENTATION 

0«^»W  ham?  ALREADY  USED  IN  DIFFERENT  CONTEXT 

COTTON  NAM F ALRFADY  USED  IN  DIFFERENT  CONTEXT 

0OTI0N  NAM*  LIST  TOO  LONG  - REST  IGNORED 

APPLE7  K^YWO^D  CANNOT  APPLY  TO  KEYWORD 

APPLE  S MAILBOX  CAN  ONLY  APTLY  TO  PD 

APPLES  SECURITY  CANNOT  APPLY  TO  SECURITY 

APPL  E S SOURCE  CANNOT  APPIY  TO  SOURCE 

APPLES  K*MO  CANNOT  APPLY  TO  MEMO 

HO°MSL  NAM*  NOT  IN  DATA  BASE  - 

ILLS T NO  CURPENT  SECTION 


Table  5. 2.1.1 
UFL  Name  Error  Messages 
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■cro  r 

Uuinber  Pin  tiros'  ic 

2?  PWLI6?  3»"E  A”'rpTn,JT2  ALREADY  GIVEN  WITH  DIPFEREN? 

*TTPTBUTE  VALUE 

HI  C”HE?  ' CARDINALITY  ALREADY  GIVEN’  A3  SYSPAF 

•1U  OTHERS  CAP  DIN  A I.  TTY  ALREADY  GIVEN  AT  DIFFERENT  VALUE 

6G  APPLET  FTC  0 NT  HAII.BCX  FOP  PD  I LI  EG  A L 

ri  mi?T  M ? TADY  PART  0*  SQKE7HTNG  ELSE 

62  pwt.tf-  SECOND  PO  for  this  HAKE  ILLEGAL 

6?  F WIT  FT  ALP  ” APY  PART  OF  SOMETHING  ELSE 

US  ’'LI  37  FIN  NO”  LEFT  THAN  MAX  ~ IGNORED 

’17  rFLES  Trvrr*”';  VALUFS  ALREADY  GIVEN 

?"S  S^TSYN  * LP  E AO Y CYN  ON Y F FOp  SOMETHING  ELSE 

711  OTHERS  ROTATION  ALREADY  EXISTS  BETWEEN  TWO  0”H Sp 

r ')TT'rI”5 

?H  O^HE^o  CAN  HAVE  ONLY  ONE  Cjr.  r^NALI^Y 

14  n"'Pt?3  CC  N ’’  PC”I  V1 1"  Y ALREADY  GIVE?:  ^OF  THIS  RELATION 

' - R WL " F E A!  ” r APY  CONTAINS  WITH  DTFFFpENT  SYSTEM 

RA'AXFTF  p 

?1S  OTHERS  rr: i’TOK  ALFEAtY  EXTS~'S  BE” WEEN  DIFF2BE Hm 

r vTI”Y 

263  F WT  I F CC”  NEC”  TON  ALFFADY  ^XTST  WITH  niFFEPEN”  VALUE 

TR  f l * F- 
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S V s^m 
Flow 

System 

Structure 

Data 

Structure 

Data 

Derivation 

P NS 

6 1,6? 

TNPUT 

61,63 

nu'ppr'i 

M , 6 3 

^NTTTY 

212,218 

’’EL1'  TT0»' 

212,218 

PPOCFcS 

61,63 

07HPP 

2F5 

2 re 

20  5 

90,205 

TA3LF  5. 2. 2.1 
CONSISTENCY  ERRORS 

CAi”  I 
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aV'TLTICS/UUL  USE!  *S  *! 

! A NTJ  AL 

- V^f 

C [t;  5 

Svr?tPir  Syst*»n 

Pyre mien  Properties 

Project 
Manaqe"en  t 

p v- 

62 

j vpn  * 

2 1 c 

62 

OUTPUT 

2 15 

6 2 

C1?T 

!»  ->  ,4U 
211,215 

62 

ENTITY 

U ’ ,L'i 

21  \214 

n 2 

EFT.ATjow 

u 7,uu 

21  3,21« 

62 

GPOTJp 

21  c 

62 

EL  EM  BN" 

117,1  1 c 

r i 

•X' 

OPOCES? 

62 

TNTE  P VAT 

2“»5 

62 

SYSTEM 

PAFAMF-EF 

265,1  15 

62 

62 

CO*'P  TTTO  N 

62 

CON  PIT  TON 

62 

CTHPP 

2"  5 

2^5  22,205 

60,62,205 

TABLE  5. 2.2.1  (continued) 
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^£JTI?2££SI!£££  Checks  Cac riel  Out  by  the 

l0.2i££i 

At  noi  n t ir,  time  in  the  development  of  the  problem 

stitomontf  t h ->  Analyst  mav  want  to  check  its  state  o f 
consistpncv  and/or  c c mpl»  toness . The  Analyst  can  perform  these 
cherts  tv  Inspection  of  various  reports  available  from  the 
Analv^er.  This  tochniaue  is  possible  because  all  information 
specified  in.  tba  data  has°  can  be  presented  via  one  or  more 
reports.  ^inc°  the  Analyzer  has  checked  all  inputs  to  the  data 
base  for  syntax  an*  consistency  errors,  the  problem  statement 
presented  is  alwavs  in  a correct  state.  Tt  is  the  role  of  the 
Analyst  to  * e t =>r  m i p <■>  whether  it  is  totally  " consistent”  or 
"complete. " 

Table  l.*  Presents  a summarv  of  all  consistency  and  completeness 
checks  to  be  carried  cut  by  the  Analyst. 

'’’able  5.3.1  prison*?  a summary  of  the  benefits  of  particular  UFA 
reports  in  identifying  inconsistencies  and  incompleteness  in  tha 
problem  statement. 
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c Y S T FM.  pLOW 

al  Ml  I NTFR F ACES  should  GENERATE  some  INPUT,  RECEIVE 
some  OUTPUT,  or  he  RESPONSIBLE  for  some  SET. 

h)  All  IV^TE  should  be  GENERATED  by  at  least  one 
I NT-’?  e'*C,;' . 

c)  All  INPUTS  should  be  RFCFTVED  bv  at  least  one 
PFOCr  SS. 

d)  All  OUTPUTS  should  he  GENERATED  by  at  least  one 
?POCr  SB. 

e)  All  o 'j^PUTS  should  be  RECEIVED  by  at  least  one 
INTER F ACr  . 


TI)  SYSTEE  S7F  UCTUR  r 

a)  All  PROOF SSES  without  SUBPAPTS  should  have 
PFOCFOMR  EE. 

b)  c FTS  with  SUBSETS  should  have  SUUSETTING-CRITEBIA . 

c)  All  INPbTS  without  SUBPAPTS  should  he  broken  down  via 
the  CONSISTS  statement. 

d)  All  ou^pu^S  without  SDBPAPTS  should  be  broken  down 
via  the  CONSISTS  statement. 


TII)  TA^A  STR  UCTU?? 

a)  All  NTS  should  be  available  from  an  INPUT  or 

from  a EN T TmY , or  DEPTVED  by  some  PROCESS . 

b)  All  SETS  should  CONSIST  of  INPUTS,  OUTPUTS  or 

TI""TT'T’’5i 

c)  All  ENTITIES  should  be  broken  down  via  the  CONSISTS 
s t a * e m en  t.  . 

d)  All  INPUTS  should  be  broken  down  via  the  CONSISTS 
statement  if  there  arp  r.o  SUBPAPTS. 

e)  All  omUTS  should  be  broken  down  via  the  CONSISTS 
statemen*-  if  there  are  no  SUBPAPTS. 

f)  »U  RELATIONS  should  have  a BETWEEN  statement. 

i)  All  group?  should  be  composed  of  ELEMENTS. 


"able  5.3a 

Summary  of  Completeness  Checks  to  be  made  by  Analyst 
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TV) 


DATA  DPcrvs-’-rM 

?.)  *11  : LFK  r V TF  should  he  USFD,  U PD A 7 ED  and/or  DERIVED 

h v a*-  1»3  Kt.  onp  PFOCF3S. 

M All  RROCTSS73  should  acquire  information  by 
’:CTTVT»'r.,  M5ING  or  UP^MING. 

c)  A1!  °ROCFS3?5  should  produce  information  by 
^ F wp  J N G , DFET VI  NO  , or  UPDATING. 

d ) *11  o ?tC  should  h«  USED,  UPDATED  or  DERIVED  by  at 
l oast  one  PPOCESS  . 

e)  All  should  have  a DERIVATION  statement. 

♦j  All  “vi'-tTI?^  should  be  PEED , UPDATED  or  DERIVED. 

0)  All  "LEM  NTS  within  an  INPUT  should  be  USED. 

hi  *11  ELEMENTS  Within  an  r UTPU7  should  he  DERIVED. 

1)  *11  "L  FK  r N TS  within  an  ENTr~Y  should  be  USED,  UPDATED 

or  "DRIVED. 

i)  All  - ELAT  TONS  should  be  HAI!*T A TNED  by  at  least  one 

r>  c oce  c c , 

V ) AM  "EL/T IONS  should  have  a DERIVATION  statement. 


V) 


C yg  TPV 
^ > 
h) 

c) 

d) 

°) 

f) 

0) 

h) 

i) 
i) 

V) 


SI7r  * ND  VOLUEF 

All  "V"NTS  should  have  a HapPES*  statement. 

All  PROCESSES  should  have  a HAPPENS  statement. 

*11  should  have  a CARDIN  All"  Y statement. 

All  '•ETC  should  have  a VCIATI  I.ITy-SET  statement. 
All  EFT*  should  have  a VOLATILITY-MEMBER  statement 
All  -Ntttjfs  should  have  a CARDINALITY  statement. 
*11  F NT  IT  T EE  should  have  a HAPPENS  statement. 

All  T VPUT  S should  have  a HAPPENS  statement. 

A11  outputs  should  have  a HAPPENS  statement. 

All  R PLAT T ONE  should  have  a CARDINALITY  statement. 
All  vtimiquc  should  have  a C0NN5C" . VITY  statement 


»T)  EYSTIV  nvtMic? 

a)  Each  even"1  should  be  associated  with  at  least  one 
CONDITION  or  PROCESS . 

b)  Each  CONDITION  should  be  associated  with  at  least  one 
rVENT  or  PROCESS. 

c)  Cach  CONDITION  should  have  a TPOE  WHILE  or  PALSE 

statement. 


VII)  SY^-RM  upon^p'jjpg 

a)  *11  KEYWOFDS,  ATTRIBUTES,  SOURCES,  SECURITIES  and 
TRACE-KEY"  should  APPLY  to  some  other  URL  names. 


VIII)  nF  0'TrCT  MANAGEMENT 

a)  All  nRODLFy-DEFINEPS  should  have  a MAILBOX, 

h)  All  PROPLEM-DEFINEFS  should  be  RESPONSIBLE  for  the 

description  of  at  least  one  URL  objects. 


Table  5.3a  (continued) 
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Analyzer  Commands 


Completeness  Checks 


VT  T a 


A^TF  TPf""  i INFORMATION  P7P0C'T’ 
fTI'IS"1'  CO'i  P A- ” SON  7.ATPIY 
C0N-7NT7  P7PO  ,J~ 

T'An'*  ?FOC7c3  c-nDp'r- 

pn  Pi'  AT'"'17  0 °cOPTr1  ST>T?MFNT 


f?70UFNCY  ’’o-i1” 

V5  1~  G?V. 

PTC"’’  U?F 

PPOr?5?  INPTJ""  AVI  rpn"' 
nrTNCPEn  COWMEN"  7 VT  A I E7 


IITc,  ~IId,  Tile,  Illq 
ITTc,  Hid,  TIIe,  II I q 
Ic,  II;  IVa,  IVh,  IVc,  IVd,  ivf 
la-  le;  Ila-IId;  Illa-IHq; 
IVa-IVf , 

IVi,  I Vi ; Va-Vk;  Vla-VIr;  Vlllb 
Va,  Vh,  vh,  Vi 
Villa,  V ITIb 

la,  lb,  Ic,  Id,  Ie;  lib,  IIC, 

I Id 

IVb,  IVc 

IVe,  IVi,  Vd,  Ve,  Vq 


Table  ?.3b 

U3A  Rcnorbs  bhat  may  be  used  by  visually  Check 
for  Completeness  of  the  Problem  Statement 
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OR®  ■>“nor!'  Counletenpss  Checks 

CONSISTS  COMPARISON  - All  INPUTS,  OUTPUTS,  ENTITIES  and  GROUPS 
MA  T FIX  are  broken  down  To  ELEMENTS  at  the  lowest 

level  . 

All  necessary  ELEMENTS  are  defined  in  the 
data  structure  for  a particular  INPUT, 
OUTPU't  or  ENTITY. 

CONSISTS  MATRIX  - All  GROUPS  and  ELEMENTS  belong  to  higher 

level  data  structures. 

All  SETS  broken  into  INPUTS,  or  0 U71  PUTS 
or  ENTITIES1 

All  INPUTS,  OUTPUTS,  ENTITIES  and  GROUPS 
are  broken  down  to  ELEMENTS  at  the  lowest 
level . 

All  SETS  broken  into  INPUTS,  or  OUTPUTS 
ENTITIES 

All  INPUTS  RECEIVED  by  sole  PROCESS® 

All  INPUTS  USED  by  some  PROCESS* 

All  OUTPUTS  GENERATED  by  some  PROCESS* 

All  OUTPUTS  DERIVED  by  some  PROCESS* 

All  ENTITIES  and  SETS  DERIVED  by  some 
PFOCESS* 

All  ENTITIES  and  SETS  DERIVED  and  USED  by 
some  PROCESS* 

All  ENTITIES  and  SETS  are  UPDATED  and 
USED  by  some  PROCESS* 

All  GP00PS  and  ELEMENTS  are  DERIVED  or 
UPDATED  or  USED  by  some  PROCESS* 

All  PROCESSES  USE  data  and  DERIVE  or 
UPDATE  data* 

All  PROCESSES  which  DERIVE  data  also  USE 
da  ta* 

All  PROCESSES  which  UPDATE  data  also  USE 
data* 

All  PROCESSES  interact  with  data  in  some 
wa  v* 

DICTIONARY  PEPOR”'  - All  names  should  have  a narrative 

T>ESCPTnTTON  and 
RESPONSIRL^-PROBL  EK-DEEINER 

DYNAMIC  ANALYSTS  - All  the  dynamic  relations  for  CONDITIONS, 

EVENTS,  PROCESS  and  INPUTS  are  broken 
down  to  the  lowest  level. 

"“able  5.3.1 

Com plet enes g and  Consistency  Checks  Made  by  UFA  Reports 


* Com  miter- aided  analysis 
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DA "A  PROCESS  REPORT  - 
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EXTENDED  PIC U "r  F 


"DEN  IT p IE?  TNPOr~ 
‘,ATTCN  RFPO’;'" 


Ml  SETS  ar?  broker  into  ENTITIES  or 
INPUTS  or  SETS 

All  PrOCESS  interact  with  data  in  some 
manner 

Ml  INTERFACES  aenf-rate  INPUTS  to  the 
SYSTEM  and/or  receive  OUTPUTS 
All  OUTPUTS  are  aenerated 

Ml  INPUTS  generated  must  be  used  in  some 
manna  r 

All  SETS  are  used,  updated  or  derived 
All  I NPU'T,  OUTPUT,  ENTITY  are  produced 
and/or  used  in  some  manner 
All  3F0UP,  ELEMENT  are  produced  and/or 
used  in  some  manner 

All  INPUT,  OUTPUT,  GROUP,  ENTITY  are 
eventually  broken  down  into  elements 
All  GROUP,  ELEMENT  are  contained  within 
some  ] arqer  data . 

Determines  which  ENTITIES  have  and 
do  not  have  IDENTIFIERS 


INTERVAL  CON  SISTT’TY 


All  INTERVALS  are  broken  down  into 
'■jjt'yfvalS  at  the  lowest  level 


p0T'  AT?PD  P° o r,T,  F \ - "ho  description  of  each  name  can  be 

?TA"’EMTrT  checked  aqainst.  all  possible  statements 

for  that  name. 


r,,F0 (i y FED0':'“I 


KWT  INDEX 

"A  ME  GWW 


1 1ST 


PTC"  'JFF 


All  INPUTS,  CUPTPUTS , PROCESSES  and 
EVF'ITS  should  have  a HAPPENS  statement 


All  names  of  a particular  type  (e.o., 
PFOCISS)  have  been  defined  for  a 
particular  problem  statement 

Names  which  have  svnonyms  in  the  real 
world  should  have  them  in  t.he  prohlem 
statement 

[aiver.  in  Table  2.1b] 

Ml  names  should  be  involved  in  structure 
and/or  information  flow  of  the  problem 
statement » 


Table  S.3.1  (Continued) 
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T?n  CO  U7NC  Y PF.pon- 


Ku~r  T\PrY 


NAMr  GFTJ 


jj  ^ v ITF'T‘ 


PTr,T  'IF'11’ 


^ - ntj<"  p itd-jo"- 


SS  INPM'"  / 
P'lT 


Determines  whether  or  rot  the  manner  in 
which  frequencies  (HAPPENS  statement)  are 
assigned  is  consistent. 


Determines  whether  or  not  conventions 
used  in  assigning  names  is  consistent 


Determines  whether  or  not  naming  is 
consi stem* 

Determines  whether  or  not  name  types  have 
been  assigned  correctly. 


Determines  whether  or  not  naming  is 
consi stent 

Determines  whether  or  not  name  types  have 
been  assigned  correctly 

Determines  whether  or  not  SYNONYMS  have 
been  assinned  correctly 


Determines  whether  or  not  the  name  the 
PICT(lCP  is  oenerated  for  relates  to  the 
structure  and  information  flow  aspects  of 
the  problem  statement  correctly 


Determines  whether  or  not  the  conventions 
of  assianing  ATTPIBUTFS  is  consistent 


Dp^nr’iiines  whether  or  not  the 

manner  in  which  PFOCPS5FS  are  described 

is  consistent 


npocFcs  CHAIN 


Determines  whether  or  not  the  name 
th-'1  P FOCFFS-CHATN  is  generated  for 
relates  to  the  dynamic  aspects  of  the 
problem  statement  correctly. 

•"able  5.2.1  (Continued) 
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coraou*er  4,  22,  23,  3 7,  38,  39,  110  , PH,  189,  190 
function  21,  37,  77,  161,  162,  163,  16a,  185 

lanniiaq®  a,  =,  99,  4C,  5a,  55;  112,  123,  184  , 189,  191 
s vs*  eis  1,  5,  17,  77,  55,  €’,  73,  1 3 1 , 119 
AFC""  96  , 109,  196,  1 41  , 166  , 174,  195 

IMPLIES  23,  2°,  30,  31,  35,  112,  113,  <16,  119,  120,  180,  183, 

194 


A q 3 F **  T 28,  2°, 

35,  1 1 2,  114, 

1i7 

9 

127, 

1 32, 

137, 

141, 

146, 

151, 

15  4,  1 6 C , 

169,  17A,  172 

, 174, 

176 

, 177, 

178, 

179, 

1 80, 

1 82 

A~SOCIATFD  28, 

29,  3 0,  34,  76,  11, 

78, 

80,  157,  187 

A 55  OCT  AO  FD-D  AT' 

A 28,  79,  3 C , 

34, 

76 

, 77 

, 152, 

154, 

157 

^ ■"'"'3  V.  1 f , 

38,  24,  25,  28 

, 2° 

9 

31, 

35  , 41 

, 72 , 

112, 

1 13, 

114, 

'116,  117, 

118,  924,  128 

, 127, 

132 

, 137, 

141, 

146, 

151, 

154, 

159,  1 6 P , 

160,  1 7n , 172 

, V7*, 

176 

, 177, 

178, 

179, 

180, 

192, 

196,  2^1, 

202,  205,  2C7 

A”TF  ”B!irr*-VM.T?  16,  18,  24, 

25, 

35 

, 41 

, 112, 

113, 

116, 

124, 

126, 

127 , 

1 94 

OFCOVFS  1C6,  107,  166,  167, 

173 

PROOFING  10 2 , 

135,  172 

9F”WEEf?  28,  23 

, 7*,  77,  78, 

79, 

ec 

, 152,  154 

, 157 

, 196 

, 20  0 

Com^an'’  II7,  118,  123 

CAPDTNAIITY  29 

, 2°,  30,  34, 

81  , 

93 

, 96 

, 100 , 

101. 

145, 

1 50, 

154, 

138,  109, 

196,  201 

CAPPED  28,  29, 

3%  3%  1C 2,  103, 

105, 

106, 

173 

CAPS**  28,  2°, 

3 0 , 3C,  1 "2,  105, 

136, 

172, 

173,  174 

CL  AS  S I FT  C A-"  T C N 

16,  IP,  ?U,  25,  28 

, 30, 

34, 

41,  66,  7f,  93,  124, 

135,  13Q, 

14",  1 45,  150  , 159 

, 181 

CONDITION  16, 

18,  72,  35,  36,  41, 

101, 

102, 

10  3,  105,  106,  1 07, 

124 , 

136 

, 166, 

168, 

171 , 17?, 

173, 

174, 

198, 

201,  203 

CONN FCT  T V 

r*ny 

28, 

29, 

70, 

34,  79,  80 

, 96, 

100 

, 153 

, 1 54,  196,  201 

CON  SI 5^ 0 

2°, 

28, 

39, 

34, 

66,  76  , 77 

, 78, 

79, 

52, 

83,  96,  97, 

100  , 

1 9 a 

, 1 

1C 

- ' 9 

1 70, 

142,  <48, 

156, 

170, 

187, 

195,  200,  202, 

20.7, 

20  6 

CONVOKED 

TO 

'■  » 

78, 

3C, 

35, 

108,  i09. 

111, 

177 

con. snips 

28, 

00 

- 9 

70  , 

3S 

108,  1"9, 

no. 

111, 

175 

COir  ATNF  D 

28, 

29 

, 3" 

, 34 

, «6,  76,  77,  78 

, 80 

, 82, 

83  , 90  , 94  , 

c 6 , 76,  11,  17U,  190,  1 42  , 15  2,  156  , 187,  1 88 
COT"  ENTS  32,  93,  202,  2*3,  2,'6 
OF  w 7*1?  41,  129,  18C,  1«1,  182,  1 8C  , 194 

DELS 7Y -nSL 


rrpr  «jr\T>; 9 u * 

?c,  60,  6-,  no. 

88,  89,  °2 , 73 

, 102,  105,  106, 

770,  133, 

176,  138,  147, 

144,  147, 

153, 

153,  15  9,  161, 

182, 

161,  164, 

17.8,  1 66  , 167  , 

169,  174, 

131 

PPnTNpS  28,  ?■> 

T y AmJ  ON  18, 

79,  30,  94,  34, 

93,  "4, 

150, 

153,  154,  23  1 

PE7TVE  47,  44, 

84,  °c,  87,  49, 

13S,  143 

, 148 

, 157,  163,  185, 

207  , 2*r 

7 E 8 T v T !)  78,  ">o 

, 3",  74,  84,  95 

, 9«,  92, 

77, 

7 4,  95,  140,  1 42 

f 

14  4 , 14  9, 

•Si’,  1*8,  IS", 

161,  163, 

194, 

135,  186,  1 83, 

200, 

20  i , ? 7 7 

n-,T  7 v »c  28,  27 

, 37,  34,  84,  95 

, 97,  88, 

37, 

90,  91,  94,  1i7, 

137,  16^, 

164,  <65,  1 °9 , 

2 re. 

773c  NTPC  TON  2 3 

, 3%  95,  43,  *4 

, 63,  04, 

112, 

113,  117,  125, 

127, 

1 7 r , i?7. 

14',  "46,  151, 

154,  159, 

16.0, 

169,  170,  172, 

174, 
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20^ 


17f 

» 

<-7, 

no 

9 

1 

TO 

» 

’86  , 

1 «2, 

203  , 

2p5, 

206 

p r 3 ▼ 

ON. A" 

V 

■>'■>  1 

■ - , 

J 

9 

> 

124 

, 183 

DIOT I OK  A 

z 

Y 119, 

->  r i 

r 

2 j6 

nyprj 

'% 

?%  ~r 

9 

p% 

7% 

c% 

97,  9 

7,  93 

, 102 

, 105 

/ 106, 

130, 

1 ? 7 

9 

i 3u , 

1 

76, 

1 

78, 

141 , 

1 44, 

1 49, 

153, 

158, 

159, 

1 61  , 

162 

163 

9 

ica. 

* 

6% 

1 

66, 

167, 

1‘9, 

174, 

191 

TT  T M 

IT  AJT 

16,  13, 

26, 

2 

1/  2 

2,  3 

6,  34 

/ 41, 

42, 

72,  73,  76, 

77, 

78, 

9?  , 3 > 

9 

oc 

87, 

79,  89,  <r 

, 31, 

92, 

93,  94 

/ 95, 

96, 

i rr 

9 

11% 

* 

74, 

34, 

135, 

134, 

140, 

14?, 

143, 

144, 

1 50, 

152 

icr 

9 

1 9 7 

i 

5% 

1 

59, 

163  , 

’64, 

184  , 

185, 

187, 

188, 

193, 

19  4, 

T on 

9 

29  9 ) 

°% 
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c 

03, 

2n4 

•'OT 

?Y  41 

£ 
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■A 
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* 

/ 72 

, 34 

, 41, 

73, 

74,  7%  77 
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Q O 

6 f 

(H,  34 

9 

qc 

' 9 

07 

9°, 

99,  0 

% 71 

/ c% 

43, 

94,  95 

96, 

19 

A 

24, 

1 

42, 

147  , 

1 44, 

14% 

147, 

148  , 

149, 

150, 

151, 

ic  *> 

i;  i 

1 

74, 

A 

36  , 

167, 

163, 

164, 

181, 

1 94  , 

195, 

1 96  , 

187 

i »<  p 

13  7, 

* 

O r 

9 

“I 

OS 

/ 

197, 

1 78  , 

200  , 

201, 

703  , 

20  4, 

206 

-TV7N' 

- 1C 

17  , "• 

2 

r 

« ■-» 

f 

36, 

41  , 

42, 

36,  1 

00,  1 

01,  1 

02,  103,  105, 

1 ’6 

ri, 

74, 

1 

•ar 

166  , 

In'7, 

169, 

17% 

172, 

173, 

174, 

19  8. 

- « i 

/ 

Vi  1 

* 

"4, 

2 

Y nc 

1l-  ^ 

i 

3r'/ 

* 

4C  , 

16  6 , 

174 
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«’.??  V%  %%  105,  106,  1C"7,  136,  166  , 167,  169,  171, 


17  O *1  “» 

1 - 9 * 

■3 

7. 

V .0  •-?  V 

0 

•r 

TT 

v - ^ 

* 

83 

v r»  rr  r\  r j r »j  y * 

n 

# 

*>  *- 

*■■  / 

"4,  ‘ 

2^7 

'iFNB^V^F^  * * 

/ 

; r, 

9 

2% 

2'- 

, 3C,  34,  42 

7*  , 

6 0, 

61,  63,  68, 

*7  r 01 

/ 1 # 

i/i 

r 

+ * *5 

134 

/ 1 

38,  1 3 Q , 142 

194 

, 186,  200,  203 

GEN r P A"" 3 10 

9 

1 -i 

1 0 
f «- 

? c 

‘ 9 

28 

, 29,  3%  34 

41, 

42, 

59,  61  , 63, 

c%  n% 

7 1 

/ 

1 5* 

*31 

, 161,  162,  198 

3C5 

G=0NP  16,  19 

9 

*■% 

r 

^ A 

9 *- 

O £ 

' ^ 

?4 
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